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Adds a binary WML token for the 
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Correction of WML Public 
Identifier 


Corrects the SGML public 
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CR-WML-vl 3-2000-02- 
15-SEC-04 


Clarification of Input 
Element 


Further revision to previously 
selected CR 


WML-IBM-20000330-r3- 
AcceptCharset 


Correct Description of 
accept-charset attribute 


Clarifies the description of the 
accept-charset attribute. 


CREC-WML-vl 3-2000- 

03-29-SEC-format- 

correction-1 


The input element format 
correction 


Modifications to input format 
codes for non-ASCII-based 
character sets. 


CREC-WML-1 .3-2000-03- 
24-PHONE-format-O 


Input Element Format 


Loosens restrictions on format 
codes "X" and "x" that were over- 
tightened in the 1 .3 draft. 


WML-IBM-20000528- 
EventOverride 


Event Override Text 


Correct misuse of [RFC21 19] 
terminology in discussion of 
overriding intrinsic events. 


Editorial Changes: 


Section 


Change 


11.1 Document Prologue 


Changed "1.2" to "1.3" in example prologue. 


11.4 The Template Element 


Capitalisation errors remaining from WML 1 .0 fixed. 


All 


SCR numbering has been reconciled with the WML 1 . 1 SCRs. 


All 


Extraneous page breaks have been removed. 
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1. Scope 

Wireless Application Protocol (WAP) is a result of continuous work to define an industry-wide 
specification for developing applications that operate over wireless communication networks. The 
scope for the WAP Forum is to define a set of specifications to be used by service applications. 
The wireless market is growing very quickly and reaching new customers and services. To enable 
operators and manufacturers to meet the challenges in advanced services, differentiation, and 
fast/flexible service creation, WAP defines a set of protocols in transport, session, and application 
layers. For additional information on the WAP architecture, refer to "Wireless Application 
Protocol Architecture Specification" [WAP]. 

This specification defines the Wireless Markup Language (WML). WML is a markup language 
based on [XML] and is intended for use in specifying content and user interface for narrowband 
devices, including cellular phones and pagers. 

WML is designed with the constraints of small narrowband devices in mind. These constraints 
include: 

• Small display and limited user input facilities 

• Narrowband network connection 

• Limited memory and computational resources 
WML includes four major functional areas: 

• Text presentation and layout - WML includes text and image support, including a variety of 
formatting and layout commands. For example, boldfaced text may be specified. 

• Deck/card organisational metaphor - all information in WML is organised into a collection of 
cards and decks. Cards specify one or more units of user interaction (e.g., a choice menu, a 
screen of text or a text entry field). Logically, a user navigates through a series of WML cards, 
reviews the contents of each, enters requested information, makes choices and moves on to 
another card. 

Cards are grouped together into decks. A WML deck is similar to an HTML page, in that it is 
identified by a URL [RFC2396] and is the unit of content transmission. 

• Inter-card navigation and linking - WML includes support for explicitly managing the 
navigation between cards and decks. WML also includes provisions for event handling in the 
device, which may be used for navigational purposes or to execute scripts. WML also supports 
anchored links, similar to those found in [HTML4]. 

• String parameterisation and state management - all WML decks can be parameterised using a 
state model. Variables can be used in the place of strings and are substituted at run-time. This 
parameterisation allows for efficient use of network resources. 
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2. Document Status 

This document is available online in the following formats: 
• PDF format at http://www.wapforum.org. 

2.1 Copyright Notice 

© Copyright Wireless Application Forum Ltd, 1998, 1999, 2000. 

Terms and conditions of use are available from the Wireless Application Protocol Forum Ltd. web 
site at http://www.wapforum.org/docs/copyright.htm. 

2.2 Errata 

Known problems associated with this document are published at http://www.wapforum.org. 

2.3 Comments 

Comments regarding this document can be submitted to the WAP Forum in the manner published 
at http://www.wapforum.org. 

2.4 Document History 



Document: Wireless Markup Language (WML) 

Current: WAP-191 
Revision History: 



ApproMil Date 


Document Identifier 


30 Apr 1998 


WAP- 106 (WML 1.0) 


16 Jun 1999 


WAP-136(WML 1.1) 


4 Nov 1999 


WAP- 155 (WML 1.2) 


7 July 2000 


WAP-191 (WML 1.3) 
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4. Definitions and Abbreviations 
4.1 Definitions 

The following are terms and conventions used throughout this specification. 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be 
interpreted as described in [RFC21 19]. In the absence of any such terms, the specification is to be 
interpreted as "MUST". 

Author - an author is a person or program that writes or generates WML, WMLScript or other 
content. 

Card - a single WML unit of navigation and user interface. May contain information to present to 
the user, instructions for gathering user input, etc. 

Character Encoding - when used as a verb, character encoding refers to conversion between 
sequence of characters and a sequence of bytes. When used as a noun, character encoding refers to 
a method for converting a sequence of bytes to a sequence of characters. Typically, WML 
document character encoding is captured in transport headers attributes (e.g., Content-Type's 
"charset" parameter) or the XML declaration defined by [XML]. 

Client - a device (or application) that initiates a request for connection with a server. 

Content - subject matter (data) stored or generated at an origin server. Content is typically 
displayed or interpreted by a user agent in response to a user request. 

Content Encoding - when used as a verb, content encoding indicates the act of converting content 
from one format to another. Typically the resulting format requires less physical space than the 
original, is easier to process or store, and/or is encrypted. When used as a noun, content encoding 
specifies a particular format or encoding standard or process. 

Content Format - actual representation of content. 

Deck - a collection of WML cards. A WML deck is also an XML document. 

Device - a network entity that is capable of sending and receiving packets of information and has a 
unique device address. A device can act as both a client and a server within a given context or 
across multiple contexts. For example, a device can service a number of clients (as a server) while 
being a client to another server. 

JavaScript -a.de facto standard language that can be used to add dynamic behaviour to HTML 
documents. JavaScript is one of the originating technologies of ECMAScript. 

Man-Machine Interface - a synonym for user interface. 
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Origin Server - the server on which a given resource resides or is to be created. Often referred to 
as a web server or an HTTP server. 

Resource - a network data object or service that can be identified by a URL. Resources may be 
available in multiple representations (e.g., multiple languages, data formats, size and resolutions) or 
vary in other ways. 

Server - a device (or application) that passively waits for connection requests from one or more 
clients. A server may accept or reject a connection request from a client. 

SGML - the Standardised Generalised Markup Language (defined in [IS08879]) is a general- 
purpose language for domain-specific markup languages. 

Terminal - a device providing the user with user agent capabilities, including the ability to request 
and receive information. Also called a mobile terminal or mobile station. 

Transcode - the act of converting from one character set to another, e.g., conversion from UCS-2 
to UTF-8. 

User - a user is a person who interacts with a user agent to view, hear or otherwise use a resource. 

User Agent - a user agent is any software or device that interprets WML, WMLScript, WTAI or 
other resources. This may include textual browsers, voice browsers, search engines, etc. 

WMLScript - a scripting language used to program the mobile device. WMLScript is an extended 
subset of the JavaScript™ scripting language. 

XML - the Extensible Markup Language is a World Wide Web Consortium (W3C) standard for 
Internet markup languages, of which WML is one such language. XML is a restricted subset of 
SGML. 



4.2 Abbreviations 



For the purposes of this specification, the following abbreviations apply. 



BNF 



Backus-Naur Form 



HDML 



Handheld Markup Language [HDML2] 



HTML 



HyperText Markup Language [HTML4] 



HTTP 



HyperText Transfer Protocol [RFC2068] 



IANA 



Internet Assigned Number Authority 



MMI 



Man-Machine Interface 



PDA 



Personal Digital Assistant 
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RFC 


Request For Comments 


SGML 


Standardised Generalised Markup Language [IS08879] 


UI 


User Interface 


URL 


Uniform Resource Locator [RFC2396] 


URN 


Uniform Resource Name 


W3C 


World Wide Web Consortium 


WAE 


Wireless Application Environment [WAE] 


WAP 


Wireless Application Protocol [WAP] 


WSP 


Wireless Session Protocol [WSP] 


XML 


Extensible Markup Language [XML] 



4.3 Device Types 

WML is designed to meet the constraints of a wide range of small, narrowband devices. These 
devices are primarily characterised in four ways: 

• Display size - smaller screen size and resolution. A small mobile device such as a phone may 
only have a few lines of textual display, each line containing 8-12 characters. 

• Input devices - a limited, or special-purpose input device. A phone typically has a numeric 
keypad and a few additional function-specific keys. A more sophisticated device may have 
software-programmable buttons, but may not have a mouse or other pointing device. 

• Computational resources - low power CPU and small memory size; often limited by power 
constraints. 

• Narrowband network connectivity - low bandwidth and high latency. Devices with 300bps to 
10kbps network connections and 5-10 second round-trip latency are not uncommon. 

This document uses the following terms to define broad classes of device functionality: 

• Phone - the typical display size ranges from two to ten lines. Input is usually accomplished 
with a combination of a numeric keypad and a few additional function keys. Computational 
resources and network throughput is typically limited, especially when compared with more 
general-purpose computer equipment. 
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• PDA - a Personal Digital Assistant is a device with a broader range of capabilities. When used 
in this document, it specifically refers to devices with additional display and input 
characteristics. A PDA display often supports resolution in the range of 160x100 pixels. A 
PDA may support a pointing device, handwriting recognition and a variety of other advanced 
features. 

These terms are meant to define very broad descriptive guidelines and to clarify certain examples in 
the document. 
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5. WML and URLs 

The World Wide Web is a network of information and devices. Three areas of specification ensure 
widespread interoperability: 

• A unified naming model. Naming is implemented with Uniform Resource Locators (URLs), 
which provide standard way to name any network resource. See [RFC2396]. 

• Standard protocols to transport information (e.g., HTTP). 

• Standard content types (e.g., HTML, WML). 

WML assumes the same reference architecture as HTML and the World Wide Web. Content is 
named using URLs and is fetched over standard protocols that have HTTP semantics, such as 
[WSP]. URLs are defined in [RFC2396]. The character set used to specify URLs is also defined in 
[RFC2396]. 

In WML, URLs are used in the following situations: 

• When specifying navigation, e.g., hyperlinking. 

• When specifying external resources, e.g., an image or a script. 

5.1 URL Schemes 

WML browsers must implement the URL schemes specified in [WAE]. 

5.2 Fragment Anchors 

WML has adopted the HTML de facto standard of naming locations within a resource. A WML 
fragment anchor is specified by the document URL, followed by a hash mark (#), followed by a 
fragment identifier. WML uses fragment anchors to identify individual WML cards within a WML 
deck. If no fragment is specified, a URL names an entire deck. In some contexts, the deck URL 
also implicitly identifies the first card in a deck. 

5.3 Relative URLs 

WML has adopted the use of relative URLs, as specified in [RFC2396]. [RFC2396] specifies the 
method used to resolve relative URLs in the context of a WML deck. The base URL of a WML 
deck is the URL that identifies the deck. 
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6. WML Character Set 

WML is an XML language and inherits the XML document character set. In SGML nomenclature, 
a document character set is the set of all logical characters that a document type may contain (e.g., 
the letter T and a fixed integer identifying that letter). An SGML or XML document is simply a 
sequence of these integer tokens, which taken together form a document. 

The document character set for XML and WML is the Universal Character Set of ISO/IEC- 10646 
([ISO 10646]). Currently, this character set is identical to Unicode 2.0 [UNICODE]. WML will 
adopt future changes and enhancements to the [XML] and [ISO 10646] specifications. Within this 
document, the terms ISO 10646 and Unicode are used interchangeably and indicate the same 
document character set. 

There is no requirement that WML decks be encoded using the full Unicode encoding (e.g., UCS- 
4). Any character encoding ("charset") that contains a proper subset of the logical characters in 
Unicode maybe used (e.g., US-ASCII, ISO-8859-1, UTF-8, ShiftJIS, etc.). Documents not 
encoded using UTF-8 or UTF-16 must declare their encoding as specified in the XML 
specification. 



( onformunce Rules: 




WML-01 UTF-8 Encoding 


0 


WML-02 UTF-16 Encoding 


0 


WML-03 UCS-4 Encoding 


0 


WML-04 Other character encoding 


0 


6.1 Reference Processing Model 



WML documents maybe encoded with any character encoding as defined by [HTML4]. 

Character encoding of a WML document may be converted to another encoding (or transcoded) to 
better meet the user agent's characteristics. However, transcoding can lead to loss of information 
and must be avoided when the user agent supports the document's original encoding. Unnecessary 
transcoding must be avoided when information loss will result. If required, transcoding should be 
done before the document is delivered to the user agent. 

This specification does not mandate which character encoding a user agent must support. 

Since WML is an XML application, the character encoding of a WML document is determined as 
defined in the XML specification [XML]. In normal cases it is always possible to detect the 
character encoding of the document (all other cases are error situations). The meta http-equiv 
statement, if any is present in the document, is never used to determine the character encoding. 
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If a WML document is transformed into a different format than XML - for example, into the binary 
WBXML format - then, the rules relevant for that format are used to determine the character 
encoding. 

When an WML document is accompanied by external information (e.g. HTTP or MIME) there may 
be multiple sources of information available to determine the character encoding. In this case, their 
relative priority and the preferred method of handling conflict should be specified as part of the 
higher-level protocol. See, for example, the documentation of the "text/vnd . wap . wml" and 
"application/vnd.wap.wmlc" MIME media types. 

The WML reference-processing model is as follows. User agents must implement this processing 
model, or a model that is indistinguishable from it. 

• User agents must correctly map to Unicode all characters in any character encoding that they 
recognise, or they must behave as if they did. 

• Any processing of entities is done in the document character set. 



A given implementation may choose any internal representation (or representations) that is 
convenient. 



C 'onformancc Rules: 




WML-05 Reference processing 


M 



6.2 Character Entities 



A given character encoding may not be able to express all characters of the document character set. 
For such encoding, or when the device characteristics do not allow users to input some document 
characters directly, authors and users may use character entities (i.e., [XML] character references). 
Character entities are a character encoding-independent mechanism for entering any character from 
the document character set. 

WML supports both named and numeric character entities. An important consequence of the 
reference processing model is that all numeric character entities are referenced with respect to the 
document character set (Unicode) and not to the current document encoding (charset). 

This means that &#3 02 ; always refers to the same logical character, independent of the current 
character encoding. 

WML supports the following character entity formats: 

• Named character entities, such as &amp ; and &1 1 ; 

• Decimal numeric character entities, such as &#3 2 ; 

• Hexadecimal numeric character entities, such as &#x2 0 ; 
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Seven named character entities are particularly important in the processing of WML: 



< ! ENTITY quot 


"&#3 4; "> 






quotation mark --> 


< ! ENTITY amp 


" &#3 8 ; #3 8 ; 






ampersand --> 


< ! ENTITY apos 


"&#3 9; "> 






apostrophe --> 


<! ENTITY It 


"&#60; 


-> I 




less than --> 


<! ENTITY gt 


"> "> 






greater than --> 


< ! ENTITY nbsp 


"&#16 0; "> 






non-breaking space --> 


<! ENTITY shy 


"­ "> 






soft hyphen (discretionary hyphen) --> 


C 'onformancc Rules: 








WML-06 Character entities 


M 
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7. WML Syntax 

WML inherits most of its syntactic constructs from XML. Refer to [XML] for in-depth 
information on syntactical issues. 

7.1 Entities 

WML text can contain numeric or named character entities. These entities specify specific 
characters in the document character set. Entities are used to specify characters in the document 
character set either which must be escaped in WML or which may be difficult to enter in a text 
editor. For example, the ampersand (&) is represented by the named entity &amp ; . All entities 
begin with an ampersand and end with a semicolon. 

WML is an XML language. This implies that the ampersand and less-than characters must be 
escaped when they are used in textual data, That is, these characters may appear in their literal 
form only when used as markup delimiters, within a comment, etc. See [XML] for more details. 

7.2 Elements 

Elements specify all markup and structural information about a WML deck. Elements may contain 
a start tag, content and an end tag. Elements have one of two structures: 

<tag> content </tag> 

or 

<tag/> 

Elements containing content are identified by a start tag (<tag>) and an end tag (</ tag>). An 
empty-element tag (< tag/ >) identifies elements with no content. 

7.3 Attributes 

WML attributes specify additional information about an element. More specifically, attributes 
specify information about an element that is not part of the element's content. Attributes are always 
specified in the start tag of an element. For example, 

<tag attr="abcd"/> 

Attribute names are an XML NAME and are case sensitive. 

XML requires that all attribute values be quoted using either double quotation marks (") or single 
quotation marks ('). Single quote marks can be included within the attribute value when the value is 
delimited by double quote marks and vice versa. Character entities may be included in an attribute 
value. 
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7.4 Comments 

WML comments follow the XML commenting style and have the following syntax: 

< ! - - a comment - - > 

Comments are intended for use by the WML author and should not be displayed by the user agent. 
WML comments cannot be nested. 

7.5 Variables 

WML cards and decks can be parameterised using variables. To substitute a variable into a card or 
deck, the following syntax is used: 

^identifier 

$ (identifier) 

$ (identifier: conversion) 

Parentheses are required if white space does not indicate the end of a variable. Variable syntax has 
the highest priority in WML, i.e., anywhere the variable syntax is legal, an unescaped '$' character 
indicates a variable substitution. Variable references are legal in any PCDATA and in any attribute 
value identified by the vdata entity type (see section 8.3). Variable references are illegal in 
attribute values of type CDATA (see section 10.3.5). Since XML does not allow for dollar sign 
characters in other attribute types (for example, ID and NMTOKEN), variable references are also 
illegal in those attributes 

A sequence of two dollar signs ($$) represents a single dollar sign character in all CDATA attribute 
values and in all # PCDATA text. 

See section 10.3 for more information on variable syntax and semantics. 
C 'onforminice Rules: 

WML-64 Variable references may only occur in vdata attribute values M 



7.6 Case Sensitivity 

XML is a case-sensitive language; WML inherits this characteristic. No case folding is performed 
when parsing a WML deck. This implies that all WML tags and attributes are case sensitive. In 
addition, any enumerated attribute values are case sensitive. 
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7.7 CDATA Section 

CDATA sections are used to escape blocks of text and are legal in any PCDATA, e.g., inside an 
element. CDATA sections begin with the string "< ! [CDATA [" and end with the string "] ] >". For 
example: 

<! [CDATA [ this is <B> a test ]]> 

Any text inside a CDATA section is treated as literal text and will not be parsed for markup. CDATA 
sections are useful anywhere literal text is convenient. 

Refer to the [XML] specification for more information on CDATA sections. 

7.8 Processing Instructions 

WML makes no use of XML processing instructions beyond those explicitly defined in the XML 
specification. 

7.9 Errors 

The [XML] specification defines the concept of a well-formed XML document. WML decks that 
violate the definition of a well-formed document are in error. See section 14.2.3 for related 
information. 
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8. Core WML Data Types 

8.1 Character Data 

All character data in WML is defined in terms of XML data types. In summary: 

• CDATA - text which may contain numeric or named character entities. CDATA is used only in 
attribute values. 

• PCDATA - text which may contain numeric or named character entities. This text may contain 
tags (PCDATA is "Parsed CDATA"). PCDATA is used only in elements. 

• NMTOKEN - a name token, containing any mixture of name characters, as defined by the XML 
specification. 

See [XML] for more details. 

8.2 Length 

< ! ENTITY % length " CDATA" > <!-- [0-9]+ for pixels or [0-9]+"%" for 
percentage length --> 

The length type may either be specified as an integer representing the number of pixels of the 
canvas (screen, paper) or as a percentage of the available horizontal or vertical space. Thus, the 
value "50" means fifty pixels. For widths, the value "50%" means half of the available horizontal 
space (between margins, within a canvas, etc.). For heights, the value "50%" means half of the 
available vertical space (in the current window, the current canvas, etc.). 

The integer value consists of one or more decimal digits ([0-9]) followed by an optional percent 
character (%). The length type is only used in attribute values. 

8.3 Vdata 

<! ENTITY % vdata " CDATA" > <!-- attribute value possibly containing 
variable references --> 

The vdata type represents a string that may contain variable references (see section 10.3). This 
type is only used in attribute values. 

8.4 Flow 

<! ENTITY % layout "br"> 

<! ENTITY % flow "%text; | %layout; | img | anchor | a | table "> 

The flow type represents "card-level" information. In general, flow is used anywhere general 
markup can be included. 

© Copyright Wireless Application Protocol Forum.Ltd, 1998, 1999, 2000. 

All rights reserved 



WAP-191-WML, 19 February 2000 



Page 23 (110) 



8.5 HREF 

<! ENTITY % HREF "%vdata ; "> <!-- URI , URL or URN designating a hypertext 

node. May contain variable references --> 

The HREF type refers to either a relative or an absolute Uniform Resource Locator [RFC2396]. 
See section 5 for more information. 

8.6 Boolean 

<! ENTITY % boolean " (true | false) " > 

The boolean type refers to a logical value of true or false. 

8.7 Number 

< ! ENTITY % number "NMTOKEN" > <!-- a number, with format [0-9]+ --> 

The number type represents an integer value greater than or equal to zero. 

8.8 xml:lang 

The xml : lang attribute specifies the natural or formal language of an element or its attributes. 
The value of the attributes is a language code according to [RFC 1766]. See [XML] for details on 
the syntax and specification of the attribute values. The attribute identifies to the user agent the 
language used text that may be presented to the user (i.e., an element's content and attribute 
values). The user agent should perform a best effort to present the data according to the specifics of 
the language. Nested elements can assume the parent's language or use another. Where an element 
has both text content and text based attribute values that may be presented to the user, authors must 
use the same language for both. Variable values that are placed in vdata should match the 
language of the containing element. 

An element's language must be established according to the following precedence (from highest to 
lowest): 

1 . Based on the xml : lang attribute specified for the element. 

2. Based on the xml : lang attribute specified by the closest parent element. 

3. Based on any language information included in the transport and document meta data (see 
sections 6.1 and 1 1.3.2 for more detail). 

4. Based on user agent default preferences. 

8.9 The id and class Attributes 

All WML elements have two core attributes: id and class that can be used for such tasks as 
server-side transformations. The id attribute provides an element a unique name within a single 
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deck. The attribute class affiliates an element with one or more classes. Multiple elements can 
be given the same class name. All elements of a single deck with a common class name are 
considered part of the same class. Class names are cases sensitive. An element can be part of 
multiple classes if it has multiple unique class names listed in its class attribute. Multiple class 
names within a single attribute must be separated by white space. Redundant class names as well 
as insignificant white space between class names may be removed. The WML user agent should 
ignore these attributes. 

8.10 ContentType 

<! ENTITY % ContentType "%vdata;"> <!-- media type. May contain variable 

references --> 

The ContentType type represents the media type defined in [RFC2045]. See section 9.5.1 for more 
information. 
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9. Events and Navigation 

9.1 Navigation and Event Handling 

WML includes navigation and event-handling models. The associated elements allow the author to 
specify the processing of user agent events. Events may be bound to tasks by the author; when an 
event occurs, the bound task is executed. A variety of tasks may be specified, such as navigation to 
an author-specified URL. Event bindings are declared by several elements, including do and 
onevent. 

9.2 History 

WML includes a simple navigational history model that allows the author to manage backward 
navigation in a convenient and efficient manner. The user agent history is modelled as a stack of 
URLs that represent the navigational path the user traversed to arrive at the current card. Three 
operations may be performed on the history stack: 

• Reset - the history stack may be reset to a state where it only contains the current card. See the 
newcontext attribute (section 10.2) for more information. 

• Push - a new URL is pushed onto the history stack as an effect of navigation to a new card. 

• Pop - the current card's URL (top of the stack) is popped as a result of backward navigation. 

The user agent must implement a navigation history. As each card is accessed via an explicitly 
specified URL, (e.g., via the href attribute in go element,) an entry for the card is added to the 
history stack even if it is identical to the most recent entry. At a minimum, each entry must record 
the absolute URL of the card, the method (get or post) used to access the card, the value of any 
postfields, and any request headers. The card content is not stored in the history. Variable 
references are never stored in the history. Any variable references in the history data must be 
replaced with the current value of the variables before the entry is added to the stack. 

The user agent must return the user to the previous card in the history if a prev task is executed 
(see section 9.5.2). The execution of prev pops the current card URL from the history stack when 
a prev task is executed. 

If the card is part of deck that was originally fetched using an HTTP post method, and the user 
agent must re-fetch the deck to establish the card, then the user agent must reissue any post data 
associated with fetching the original deck. The post data values must be the same values used to 
fetch the original deck. Refer to section 12.5.2 for more information on the semantics of prev. 
See [CACHE] for more information on caching semantics. 
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C 'onforminice Rules: 




WML-07 History 


M 



9.3 The Postfield Element 



<! ELEMENT postfield EMPTY> 
< ! ATTLIST postfield 
name %vdata; 
value %vdata; 
%coreattrs ; 

The postfield element specifies a field name and value for transmission to an origin server 
during a URL request. The actual encoding of the name and value will depend on the method used 
to communicate with the origin server. 

Refer to section 9.5.1 for more information on the use of postfield in a go element. 

Attributes 
name=vdata 

The name attribute specifies the field name. 
value=vdata 

The value attribute specifies the field value. 

Attributes defined elsewhere 



• id (see section 8.9) 

* class (see section 8.9) 



C onformunce Rules: 




WML-37 postfield 


M 



9.4 The Setvar Element 



<! ELEMENT setvar EMPTY> 
< ! ATTLIST setvar 

name %vdata; 
value %vdata; 
%coreattrs ; 

The setvar element specifies the variable to set in the current browser context as a side effect of 
executing a task. The element must be ignored if the name attribute doe not evaluate to a legal 
variable name at runtime (see section 7.5). See section 10.3.4 for more information on setting 
variables. 
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Attributes 
name=vdata 

The name attribute specifies the variable name. 
value=vdata 

The value attribute specifies the value to be assigned to the variable. 



Attributes defined elsewhere 




• id (see section 8.9) 




• class (see section 8.9) 




C 'onformancc Rules: 




WML-52 setvar 


M 



9.5 Tasks 

<! ENTITY % task "go | prev | noop | refresh" > 

Tasks specify processing that is performed in response to an event such as timer expiring, entering 
a card, or activating an anchor element. 



9.5.1 The Go Element 

< ! ENTITY % cache-control "(no-cache)" > 
<ELEMENT go (postfield | setvar) *> 
< ! ATTLIST go 

href %HREF; #REQUIRED 

sendreferer %boolean; "false" 

method (post | get) "get" 

enctype %ContentType ; 

" appl i cat ion/x- www- form-url encoded" 

cache-control %cache-control ; #IMPLIED 

accept-charset CDATA #IMPLIED 

%coreattrs ; 

The go element declares a go task, indicating navigation to a URL If the URI names a WML card 
or deck, it is displayed. A go executes a "push" operation on the history stack (see section 9.2). 
The UA must ignore all postfield elements of a go element if the target of the go element is a 
card contained within the current deck and if the cache-control is not specified as "no-cache". 

Refer to section 12.5.1 for more information on the semantics of go. 

Attributes 
href =HREF 

The href attribute specifies the destination URI, e.g., the URI of the card to display. 
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sendref erer=boolean 

If this attribute is true, the user agent must specify, for the server's benefit, the URI of the 
deck containing this task (i.e., the referring deck). This allows a server to perform a form of 
access control on URIs, based on which decks are linking to them. The URI must be the 
smallest relative URI possible if it can be relative at all. For example, if 
sendref erer= true, an HTTP based user agent shall indicate the URI of the current 
deck in the HTTP "Referer" request header [RFC2068]. 

method= (post \ get) 

This attribute specifies the HTTP submission method. Currently, the values of get and 
post are accepted and cause the user agent to perform an HTTP GET or POST 
respectively, 
cache -control=no- cache 

If the "cache-control" attribute is present, and the value is set to "no-cache", the client 
MUST reload the URL from the origin server. This attribute represents the HTTP "cache- 
control" header, when this attribute is present, the HTTP "cache-control" header MUST be 
added to the request with the same value as specified in the attribute. 

enctype= Con tent Type 

This attribute specifies the content type used to submit the parameter to the server (when the 
value of method is post). The default value for this attribute is application/x-www- 
f orm-urlencoded. Currently, only application/x-www- f orm-urlencoded or 
multipart/form-data can be specified. 

When the field values in a submitted form may contain characters not in the US-ASCII 
character set, it is recommended that the post method and multipart/ form-data 
[RFC2388] are used. 

User agents must explicitly specify content type for each part. If a part corresponds to a 
postfield element, its content type should be text/plain. The charset parameter is 
required when the content contains characters not in the US-ASCII character set. 
accept- char set =cdata 

This attribute specifies the list of character encodings for data that the origin server accepts 
when processing input. When the go task is executed and method= "post " has been 
specified, the user agent should encode the field names and values of all associated 
postfield elements using any one of the specified character sets. 

The value of this attribute is a comma- or space-separated list of character encoding names 
(charset) as specified in [RFC2045] and [RFC2068]. The IANA Character Set registry 
defines the public registry for charset values. 

If the accept -charset attribute is not specified or is the reserved string unknown, user 
agents should use the character encoding that was used to transmit the WML deck that 
contains the go element. 
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Attributes defined elsewhere 

• id (see section 8.9) 

• class (see section 8.9) 

The go element may contain one or more postfield elements. These elements specify 
information to be submitted to the origin server during the request. The submission of field data is 
performed in the following manner: 

1 . The field name/value pairs are identified and all variables are substituted. 

2. The user agent should transcode the field names and values to the correct character set, as 
specified explicitly by the accept - char set or implicitly by the document encoding. 



3. If the href attribute value is an HTTP URI, the request is performed according to the method 
and enctype attribute's value: 



Method 


Knctxpi' 


Process 


get 


application/x- 

www-form- 

urlencoded 


The field names and values are escaped using URI-escaping 
and assembled into an application/x-www-form- 
urlencoded content type. 

The submission data is appended to the query component of 
the URI. The result must be a valid query component with 
the original query part and the postfields combined. An 
HTTP GET operation is performed on the resulting URL. 


multipart /form- 
data 


Error. 
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Method 


Kiu'txpe 


Process 


post 


application/x- 

www-form- 

urlencoded 


The field names and values are escaped using URI-escaping 
and assembled into an application/x-www-form- 
urlencoded content type. 

The submission data is sent as the body of the HTTP POST 
request. 

The Content -Type header must include the charset 
parameter to indicate the character encoding. 




multipart /form- 
data 


The field names and values are encoded as a 
multipart/form-data content type as defined in 
[RFC2388]. 

The Content -Type header must include the charset 
parameter to indicate the character encoding when the part 
contains characters not in the US-ASCII character set. 

The submission data is sent as the body of the HTTP POST 
request. 



When enctype attribute's value is application/x-www-form-urlencoded, the field 
names and values must be encoded as follows: 



1 . The field names and values are escaped using URI-escaping, and listed in the order in which the 
postfields are presented. 

2. The name is separated from the value by and name/value pairs are separated from each 
other by "&'. See [RFC2396] for more information on the URI syntax and its escape sequence. 

It is recommended that user agents submit data with an 

application/vnd.wap. multipart . form-data content type when enctype attribute 
has a value of multipart/form-data. Some user agents may only support data submission as 
application/x-www-f orm-urlencoded content type. Such user agents may ignore 
enctype attribute. Thus, it is recommended that an origin server expect either form of submission 
(i.e., multipart/ form-data or application/x-www-form-urlencoded) when the 
enctype value is multipart/form-data. However, the origin server may assume that it will 
only receive an application/x-www- f orm-urlencoded submission when the enctype 
value is application/x-www- f orm-urlencoded. 



© Copyright Wireless Application Protocol Forum.Ltd, 1998, 1999, 2000. 

All rights reserved 



WAP-191-WML, 19 February 2000 



Page 31 (110) 



For example, the following go element would cause an HTTP GET request to the URL 
"/foo?x=l": 

<go href="/foo"> 

<postfield name="x" value="l"/> 

</go> 

The following example will cause an HTTP POST to the URL "/bar" with a message entity 
containing "w=12&y=test": 

<go href="/bar" method= "post " > 

<postfield name="w" value="12"/> 

<postfield name="y" value="test"/> 
</go> 



Conformance Rules: 




WML-29 go 


M 



9.5.2 The Prev Element 



< [ELEMENT prev (setvar)*> 
< ! ATTLIST prev 
%coreattrs ; 

The prev element declares a prev task, indicating navigation to the previous URI on the history 
stack. A prev performs a "pop" operation on the history stack (see section 9.2). 

Refer to section 12.5.2 for more information on the semantics of prev. 

Attributes defined elsewhere 



• id (see section 8.9) 

* class (see section 8.9) 



C onformunce Rules: 




WML-38 prev 


M 



9.5.3 The Refresh Element 



< [ELEMENT refresh (setvar)*> 
< ! ATTLIST refresh 
%coreattrs ; 

The refresh element declares a refresh task, indicating an update of the user agent context as 
specified by the setvar elements. User-visible side effects of the state changes (e.g., a change in 
the screen display) occur during the processing of the refresh task. A refresh and its side effects 
must occur even if the elements have no setvar elements given that context may change by other 
means (e.g., timer). 
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Refer to section 12.5.4 for more information on the semantics of refresh. 
Attributes defined elsewhere 

• id (see section 8.9) 

• class (see section 8.9) 


( 'onfbrmance Rules: 




WML-42 refresh 


M 


9.5.4 The Noop Element 




<! ELEMENT noop EMPTY> 




< ! ATTLIST noop 




%coreattrs ; 




This noop element specifies that nothing should be done, i.e., "no operation". 




Refer to section 12.5.3 for more information on the semantics of noop. 




Attributes defined elsewhere 




• id (see section 8.9) 




• class (see section 8.9) 




Conformance 
Rules: 

WML-35 noop 


M 



9.6 Card/Deck Task Shadowing 



A variety of elements can be used to create an event binding for a card. These bindings may also 
be declared at the deck level: 

• Card-level: the event-handling element may appear inside a card element and specify event- 
processing behaviour for that particular card. 

• Deck-level: the event-handling element may appear inside a template element and specify 
event-processing behaviour for all cards in the deck. A deck-level event-handling element is 
equivalent to specifying the event-handling element in each card. 

A card-level event-handling element overrides (or "shadows") a deck-level event-handling element 
if they both specify the same event. A card-level onevent element will shadow a deck-level 
one vent element if they both have the same type. A card-level do element will shadow a deck- 
level do element if they have the same name. 
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For a given card, the active event-handling elements are defined as the event-handling elements 
specified in the card that do not bind a noop task, plus any event-handling elements specified in 
the deck's template not overridden (or shadowed) in the card or bind a noop task. Shadowed event- 
handling elements, event-handling elements defined in other cards, and event-handling elements 
that bind a noop task are considered inactive elements. 

If a card-level element shadows a deck-level element and the card-level element binds a noop task, 
the event binding for that event will be completely masked. In this situation, the card- and deck- 
level elements will be ignored and no side effects will occur on delivery of the event. In other 
words, both the card-level and the deck-level elements are considered inactive elements in such a 
case. 

If a card-level element or deck-level element binds a noop task but does not shadow and is not 
shadowed by another element, then the binding for that event will also be masked and similarly 
ignored with no side effects. 

In the following example, a deck-level do element indicates that a prev task should execute on 
receipt of a particular user action. The first card inherits the do element specified in the 
template element and will display the do to the user. The second card shadows the deck-level 
do element with a noop. The user agent will not display the do element when displaying the 
second card. The third card shadows the deck-level do element, causing the user agent to display 
the alternative label and to perform the go task if the do is selected. 

<wml> 

<template> 

<do type= "options" name="dol" label= "default "> 

<prev/> 
</do> 
</template> 

<card id="first"> 

<!-- deck- level do not shadowed. The card exposes the 
deck- level do as part of the current card --> 



<!-- rest of card --> 
</card> 
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<card id=" second" > 

<!-- deck- level do is shadowed with noop. 

It is not exposed to the user --> 
<do type= "options" name= "dol " > 

<noop/> 
</do> 



<!-- rest of card --> 



</card> 



<card id="third"> 

<!-- deck- level do is shadowed. It is replaced by 

a card- level do --> 
<do type= "options" name="dol" label= "options "> 

<go href ="/options"/> 
</do> 



<!-- rest of card --> 



</card> 




</wml> 




Conformance Rules: 




WML-08 Card/Deck task Shadowing 


M 



9.7 The Do Element 



! ENTITY % task "go 
[ELEMENT do (%task ; ) 
! ATTLIST do 

type 

label 

name 

optional 
xml : lang 
Icoreattrs 



prev | noop | refresh": 



CDATA 
%vdata; 
NMTOKEN 
%boolean; 
NMTOKEN 



#REQUTRED 

#IMPLIED 

#IMPLIED 

"false" 

#IMPLIED 



The do element provides a general mechanism for the user to act upon the current card, i.e., a card- 
level user interface element. The representation of the do element is user agent dependent and the 
author must only assume that the element is mapped to a unique user interface widget that the user 
can activate. For example, the widget mapping may be to a graphically rendered button, a soft or 
function key, a voice-activated command sequence, or any other interface that has a simple 
"activate" operation with no inter-operation persistent state. When the user activates a do element, 
the associated task is executed. 
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The do element may appear at both the card and deck-level: 

• Card-level: the do element may appear inside a card element and may be located anywhere in 
the text flow. If the user agent intends to render the do element inline (i.e., in the text flow), it 
should use the element's anchor point as the rendering point. WML authors must not rely on 
the inline rendering of the do element and must not rely on the correct positioning of an inline 
rendering of the element. 

• Deck-level: the do element may appear inside a template element, indicating a deck-level 
do element. A deck-level do element applies to all cards in the deck (i.e., is equivalent to 
having specified the do within each card). For the purposes of inline rendering, the user agent 
must behave as if deck-level do elements are located at the end of the card's text flow. 

Attributes 
type= cdata 

The do element type. This attribute provides a hint to the user agent about the author's 
intended use of the element and should be used by the user agent to provide a suitable 
mapping onto a physical user interface construct. WML authors must not rely on the 
semantics or behaviour of an individual type value, or on the mapping of type to a 
particular physical construct. All types are reserved, except for those marked as 
experimental, or vendor-specific. 

User agents must accept any type, but may treat any unrecognised type as the equivalent 
of unknown. 

In the following table, the * character represents any string, e.g., Test* indicates any 
string starting with the word Test. Although experimental and vendor-specific types may 
be specified in any case, they are case-sensitive; e.g., the types VND- f oo and vnd- f oo 
are distinct. 



Table 1. Pre-defined DO types 



Type 


Description 


accept 


Positive acknowledgement (acceptance) 


prev 


Backward history navigation 


help 


Request for help. May be context-sensitive. 


reset 


Clearing or resetting state. 


options 


Context-sensitive request for options or additional operations. 


delete 


Delete item or choice. 
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JSIK 


Description 


unknown 


A generic do element. Equivalent to an empty string (e.g., 
type=" ")• 


X-*, x-* 


Experimental types. This set is not reserved. 


A/nrl * VNT) * anrl 
VI1U. , VrN-L/. ctllU. 

any combination of 
[Vv] [Nn] [Dd] . 
* 


Vendor-specific or user-agent-specific types. This set is not 
reserved. Vendors should allocate names with the format 
VND . CO -TYPE, where CO is a company name abbreviation and 
type is the do element type. See [RFC2045] for more 
information. 



label=vdata 

If the user agent is able to dynamically label the user interface widget, this attribute 
specifies a textual string suitable for such labelling. The user agent must make a best-effort 
attempt to label the UI widget and should adapt the label to the constraints of the widget 
(e.g., truncate the string). If an element can not be dynamically labelled, this attribute may 
be ignored. 

To work well on a variety of user agents, labels should be six characters or shorter in length. 
name=nmtoken 

This attribute specifies the name of the do event binding. If two do elements are specified 
with the same name, they refer to the same binding. A card-level do element shadows a 
deck-level do with the same name value (see section 9.6 for more detail). It is an error to 
specify two or more do elements with the same name in a single card or in the template 
element. An unspecified name defaults to the value of the type attribute, 
opt ional=jbooI ear* 

If this attribute has a value of true, the user agent may ignore this element. 

All active do elements that have not been designated optional must be presented to the user. 
The UA must make such elements accessible to the user in some manner. In other words, it 
must be possible for the user to activate them (i.e., initiate the tasks associated with the 
element), via some user interface element. 

All inactive do elements must not be presented to the user in a way that the user can 
activate such elements. Elements that have been designated as optional may be ignored at 
the discretion of the user agent. (For example, the author may wish to allow the user agent 
to ignore vendor-specific types that it doesn't recognise.) 
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Attributes defined elsewhere 



• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 



Conformance Rules: 






WML-26 


do 


M 


WML-66 


Two or more do elements with the same name must not be 
present in a single card or in the template element. (Note: 
An unspecified name defaults to the value of the type 
attribute.) 


M 


WML-71 


Two or more do element with the same name must not be 
present in a single card or in the template element. (Note: 
An unspecified name defaults to the value of the type 
attribute.) 


0 



9.8 The Anchor Element 



<! ELEMENT anchor ( # PCDATA | br | img | go | prev | refresh )*> 
< ! ATTLIST anchor 

title %vdata; #IMPLIED 

accesskey %vdata; #IMPLIED 

xmlrlang NMTOKEN #IMPLIED 

%coreattrs ; 

The anchor element defines a "hot spot" in the content, which is bound to the go, prev, or 
refresh task that it contains. It is expected that the user agent presents the anchor element as a 
linking element; e.g., as "hypertext." When the user selects the element, the associated task is 
executed. 

Anchors may be present in any text flow, excluding the text in option elements (i.e., anywhere 
formatted text is legal, except for option elements). It is an error to specify other than one task 
element (e.g., go, prev or refresh) in an anchor element. 

Attributes 
title=vdata 

This attribute specifies a brief text string identifying the link. The user agent may display it 
in a variety of ways, including dynamic labelling of a button or key, a tool tip, a voice 
prompt, etc. The user agent may truncate or ignore this attribute depending on the 
characteristics of the navigational user interface. To work well on a broad range of user 
agents, the author should limit all labels to 6 characters in length. 
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accesskey=vdata 

This attribute assigns an access key to an element. An access key is a single character from 
the document character set. Its purpose is to allow the user to activate a particular element 
by using a single key. The keys available will vary depending on the type of mobile device 
being used (e.g., phones will usually have "0"-"9", "*" and "#" keys). 

The user agent is not required to support accesskey. If the user agent does supports 
access keys, it should respect the requested value if possible. When this is not possible (e.g., 
the requested key does not already exist or has been defined more than once,) the user agent 
should assign available keys to the remaining elements that request them, in the order they 
are encountered in the card, until all available keys are assigned. Any remaining 
accesskey attributes are ignored. The author can not assume that the key specified will 
be the one used, nor that all elements that define an accesskey will have one assigned. 

The following elements support the accesskey attribute: A, INPUT, and ANCHOR. 

Activating an access key assigned to an element gives focus to the element. The 
action that occurs when an element receives focus depends on the element. For 
example, when a user activates a link defined by the A element, the user agent 
generally follows the link. When a user activates a radio button, the user agent 
changes the value of the radio button. When the user activates a text field, it 
allows input, etc. 

In this example, we request an access key for a link defined by the A element. 
Activating this access key takes the user to another document, in this case, a table 
of contents. 

<a accesskey=" 1 " href="http://someplace.com/specification/contents.html"> 
Table of Contents</a> 

The invocation of access keys may depend on both the user agent and the device 
on which it is running. For example, the access key may be recognised directly, or 
it may be necessary to press it in conjunction with a "command" key.. The 
recognition of access keys may be inhibited by context. For example, a device 
that recognises access keys directly may inhibit their recognition when an input 
element is active 

The rendering of access keys depends on the user agent. User agents should 
render the value of an access key in such a way as to emphasise its role and to 
distinguish it from other characters (e.g., by underlining it, enclosing it in 
brackets, displaying it in reverse video or in a distinctive font, etc.) The author 
should not refer to the specific access key value in content or in documentation, as 
the requested value may not be used. 
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Attributes defined elsewhere 




• xmlrlang (see section 8.8) 




• id (see section 8.9) 




• class (see section 8.9) 




( oiifoi'iiiuitcc Rules: 




WML-20 anchor 


M 


9.9 The A Element 




<! ELEMENT a ( # PCDATA | br 


| img )*> 


< ! ATTLIST a 




href %HREF; 


#REQUTRED 


title %vdata; 


#IMPLIED 


accesskey %vdata; 


#IMPLIED 


xmlrlang NMTOKEN 


#IMPLIED 


%coreattrs ; 




The a element is a short form of an anchor element bound to a go task without variable 


assignments. For example, the following markup: 


<anchor>f ollow me 




<go href ="destination"/> 


</anchor> 




Is identical in behaviour and semantics to: 


<a href = "destination' 


>follow me</a> 


It is invalid to nest a elements. Authors are encouraged to use the a element instead of anchor 


where possible, to allow more efficient tokenisation. 


Attributes defined elsewhere 




• xmlrlang (see section 8.8) 




• id (see section 8.9) 




• class (see section 8.9) 




• accesskey (see section 9 i 


) 


( onformunce Rules: 




WML- 19 a 


M 



9.10 Intrinsic Events 



Several WML elements are capable of generating events when the user interacts with them. These 
so-called "intrinsic events" indicate state transitions inside the user agent. Individual elements 
specify the events they can generate. WML defines the following intrinsic events: 
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Table 2. WML Intrinsic Events 



livent 


lilement(s) 


Description 


ontimer 


card, template 


The ontimer event occurs when a timer expires. 
Timers are specified using the timer element (see 
section 11.7). 


onenterf orwar 
d 


card, template 


The onenterf orward event occurs when the 
user agent enters a card via a go task or any method 
with identical semantics. This includes card entry 
caused by a script function or user-agent-specific 
mechanisms, such as a means to directly enter and 
navigate to a URL. 

The onenterf orward intrinsic event may be 
specified at both the card and deck-level. Event 
bindings specified in the template element apply 
to all cards in the deck and may be overridden as 
specified in section 9.6. 


onenterbackwa 
rd 


card, template 


The onenterbackward event occurs when the 
user agent enters a card via a prev task or any 
method with identical semantics. In other words, 
the onenterbackward event occurs when the 
user causes the user agent to navigate into a card by 
using a URL retrieved from the history stack. This 
includes navigation caused by a script function or 
user-agent-specific mechanisms. 

The onenterbackward intrinsic event may be 
specified at both the card and deck-level. Event 
bindings specified in the template element apply 
to all cards in the deck and may be overridden as 
specified in section 9.6. 


onpick 


option 


The onpick event occurs when the user selects or 
deselects this item. 



The author may specify that certain tasks are to be executed when an intrinsic event occurs. This 
specification may take one of two forms. The first form specifies a URI to be navigated to when 
the event occurs. This event binding is specified in a well-defined element-specific attribute and is 
the equivalent of a go task. For example: 



<card onenterforward="/url"> <p> Hello </p> </card> 
This attribute value may only specify a URL. 
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The second form is an expanded version of the previous, allowing the author more control over user 
agent behaviour. An onevent element is declared within a parent element, specifying the full 
event binding for a particular intrinsic event. For example, the following is identical to the 
previous example: 

<card> 

<onevent type= "onenterf orward" > 

<go href ="/url"/> 
< /onevent > 
<P> 

Hello 
</p> 
</card> 

The user agent must treat the attribute syntax as an abbreviated form of the onevent element 
where the attribute name is mapped to the onevent type. 

An intrinsic event binding is scoped to the element in which it is declared, e.g., an event binding 
declared in a card is local to that card. Any event binding declared in an element is active only 
within that element. If the event binding element specifies an intrinsic event type which does apply 
to its parent element, it must be ignored by the user agent. Conflicting event bindings within an 
element are an error. 



Conformance Rules: 




WML-09 Intrinsic Events 


M 


WML-69 Event bindings must not conflict 


M 


WML-74 Event bindings must not conflict 


O 


9.10.1 The Onevent Element 




<! ENTITY % task "go prev noop refresh" > 
< [ELEMENT onevent (%task;)> 





< ! ATTLIST onevent 

type CDATA #REQUTRED 

%coreattrs ; 

The onevent element binds a task to a particular intrinsic event for the immediately enclosing 
element, i.e., specifying an onevent element inside an "XYZ" element associates an intrinsic 
event binding with the "XYZ" element. 

The user agent must ignore any onevent element specifying a type that does not correspond to a 
legal intrinsic event for the immediately enclosing element. 
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Attributes 




type= cdata 




The type attribute indicates the name of the intrinsic event. 




Attributes defined elsewhere 




• id (see section 8.9) 




• class (see section 8.9) 




C oitforiiiiiHcc linlcsz 




WML-39 onevent 


M 



9.10.2 Card/Deck Intrinsic Events 



Event handlers for the orient er forward, orient erbackward, and ont imer intrinsic events 
may be specified at both the card- and deck-level and have the shadowing semantics defined in 
section 9.6. Handlers for these events are specified using the corresponding attribute of either the 
template or card element, or by including an onevent element within the template or 
card element. A card-level handler always overrides a deck-level handler of the same type, 
regardless of which syntax is used. 

For example, in the following deck the event handler in the card overrides the one specified in the 
template although the two have been defined using different syntax: 

<wml> 

<template> 

<onevent type= "onenterbackward" > 

<go href="aaa"/> 
< /onevent > 
</template> 

<card onenterbackward="bbb"> 

<p>xyz</p> 
</card> 
</wml> 
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10. The State Model 

WML includes support for managing user agent state, including: 

• Variables - parameters used to change the characteristics and content of a WML card or deck; 

• History - navigational history, which may be used to facilitate efficient backward navigation; 
and 

• Implementation-dependent state - other state relating to the particulars of the user agent 
implementation and behaviour. 

10.1 The Browser Context 

WML state is stored in a single scope, known as a browser context. The browser context is used to 
manage all parameters and user agent state, including variables, the navigation history and other 
implementation-dependent information related to the current state of the user agent. 



C onformunce Rules: 




WML- 10 Browser context 


M 



10.2 The Newcontext Attribute 

The browser context may be initialised to a well-defined state by the newcontext attribute of the 
card element (see section 1 1 .5). This attribute indicates that the browser context should be re- 
initialised and must perform the following operations: 

• Unset (remove) all variables defined in the current browser context, 

• Clear the navigational history state, and 

• Reset implementation-specific state to a well-known value. 

The newcontext is only performed as part of the go task. See section 12.5 for more information 
on the processing of state during navigation. 



C onformunce Rules: 




WML- 11 Initialisation (newcontext) 


M 



© Copyright Wireless Application Protocol Forum.Ltd, 1998, 1999, 2000. 

All rights reserved 



WAP-191-WML, 19 February 2000 



Page 44 (110) 



10.3 Variables 

All WML content can be parameterised, allowing the author a great deal of flexibility in creating 
cards and decks with improved caching behaviour and better perceived interactivity. WML 
variables can be used in the place of strings and are substituted at run-time with their current value. 



A variable is said to be set if it has a value not equal to the empty string. A value is not set if it has 
a value equal to the empty string, or is otherwise unknown or undefined in the current browser 
context. 



Conformance Rules: 




WML- 12 Variables 


M 



10.3.1 Variable Substitution 



The values of variables can be substituted into both the text (# PCDATA) of a card and into %vdata 
and %HREF attribute values in WML elements. Only textual information can be substituted; no 
substitution of elements or attributes is possible. The substitution of variable values happens at 
run-time in the user agent. Substitution does not affect the current value of the variable and is 
defined as a string substitution operation. If an undefined variable is referenced, it results in the 
substitution of the empty string. 

WML variable names consist of an US-ASCII letter or underscore followed by zero or more letters, 
digits or underscores. Any other characters are illegal and result in an error. Variable names are 
case sensitive. 

The following description of the variable substitution syntax uses the Extended Backus-Naur Form 
(EBNF) established in [XML]. 

var = ( "$" varname ) | 

( " $ ( " varname ( conv )?")") | 
( deprecated-var ) 



conv 


= ":" ( 


'escape" | 


"noesc 


' | "unesc" ) 








varname 


= ( 


alpha ) 


"_" 1 


alpha 


| digit )* 






alpha 


= lalpha 


I 


halpha 














lalpha 


= "a" | 


'b' 


| "c" 


"d" | 


"e" | 


" f " | 


-g" | 


'<h'< 


»i 




"j" I 


'k' 


1 


"m" | 


"n" | 


"o" | 


'P" 1 


»q» 


»r 




»s» | 


■t' 


| "u" 


"v" | 


"w" | 


"x" | 


-y" | 


" z " 




halpha 


= "A" | 


'B' 


"C" 


"D" 


"E" 


"F" 


'G" | 


„ H „ 


"I 




"J" | 


'K' 


"L" 


"M" 


"N" 


"O" 


'P" 


MQM 


»R 




»S» | 


"I" 


" U " 


"V" 


"W" 


"X" 


"Y" 


"Z" 




digit 


= "0" | 


'1' 


"2" 


3 


"4" 


"5" 


'6" 


"V" 





"8" | "9 " 

deprecated-var = "$(" varname deprecated-conv ")" 
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deprecated-conv = " : " ( escape | noesc | unesc ) 

escape = ("E" | "e") ( ( "S" | "s" ) ( "C" | "c" ) 

( "A" | "a" ) ( "P" | "p" ) 

( "E" | "e" ) )? 

noesc = ( "N" | "n" ) ( ( "0" | "o" ) ("E" | "e") 

( "S" | "s" ) ( "C" | "c" ) )? 

unesc = ( "U" | "u" ) ( ( "N" | "n" ) ("E" | "e") 

( "S" | "s" ) ( "C" | "c" ) )? 

Mixed case and abbreviated conversions have been deprecated. Authors should only use lower 
case conversions. 

Parentheses are required anywhere the end of a variable cannot be inferred from the surrounding 
context, e.g., an illegal character such as white space. 

For example: 

This is a $var 

This is another $ (var) . 

This is an escaped $ (var : escape) . 

This is an unescape $ (var runesc) . 

Other legal variable forms: $_X $X32 $Test_9A 

The value of variables can be converted into a different form as they are substituted. A conversion 
can be specified in the variable reference following the colon. The following table summarised the 
current conversions and their legal abbreviations: 



Table 3. Variable escaping methods 



Conversion 


Meet 


Noesc 


No change to the value of the variable. 


Escape 


URL-escape the value of the variable. 


Unesc 


URL-unescape the value of the variable. 



The use of a conversion during variable substitution does not affect the actual value of the variable. 

URL-escaping is detailed in [RFC2396]. All lexically sensitive characters defined in WML must 
be escaped, including all characters not in the unreserved set specified by [RFC2396]. 

If no conversion is specified, the variable is substituted using the conversion format appropriate for 
the context. All attributes defined as %HREF; default to escape conversion, elsewhere no 
conversion is done. Specifying the noesc conversion disables context sensitive escaping of a 
variable. 
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C 'onforminice Rules: 






WML-65 


Variable references must match the production rule var 


M 


WML-70 


Variable references must match the production rule var 


0 



10.3.2 Parsing the Variable Substitution Syntax 



The variable substitution syntax (e.g., $X) is parsed after all XML parsing is complete. In XML 
terminology, variable substitution is parsed after the XML processor has parsed the document and 
provided the resulting parsed form to the XML application. In the context of this specification, the 
WML parser and user agent is the XML application. 

This implies that all variable syntax is parsed after the XML constructs, such as tags and entities, 
have been parsed. In the context of variable parsing, all XML syntax has a higher precedence than 
the variable syntax, e.g., entity substitution occurs before the variable substitution syntax is parsed. 
The following examples are identical references to the variable named X: 

$X 

&#x24 ;X 
$X 
&#3 6;X 

10.3.3 The Dollar-sign Character 

A side effect of the parsing rules is that the literal dollar sign must be encoded with a pair of dollar 
sign entities in any # PCDATA text or CDATA attribute values. A single dollar-sign entity, even 
specified as &#x24 ; , results in a variable substitution. 

In order to include a '$' character in a WML deck, it must be explicitly escaped. This can be 
accomplished with the following syntax: 

$$ 

Two dollar signs in a row are replaced with a single '$' character. For example: 

This is a $$ character. 
This would be displayed as: 

This is a $ character. 

To include the '$' character in URL-escaped strings, specify it with the URL-escaped form: 
%24 

10.3.4 Setting Variables 

There are a number of ways to set the value of a variable. When a variable is set and it is already 
defined in the browser context, the current value is updated. 
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The setvar element allows the author to set variable state as a side effect of navigation. Setvar 
maybe specified in task elements, including go, prev and refresh. The setvar element 
specifies a variable name and value, for example: 

<setvar name= " location" value="$ (X) "/> 

The variable specified in the name attribute (e.g., location) is set as a side effect of navigation. 
See the discussion of event handling (section 8.8 and section 12.5) for more information on the 
processing of the setvar element. 

Input elements set the variable identified by the name attribute to any information entered by the 
user. For example, an input element assigns the entered text to the variable, and the select 
element assigns the value present in the value attribute of the chosen option element. 

User input is written to variables when the user commits the input to the input or select 
element. Committing input is an MMI dependent concept, and the WML author must not rely on a 
particular user interface. For example, some implementations will update the variable with each 
character entered into an input element, and others will defer the variable update until the input 
element has lost focus. The user agent must update all variables prior to the execution of any task. 
The user agent may re-display the current card when variables are set, but the author must not 
assume that this action will occur. 

10.3.5 Validation 

Within the WML document, any string following a single dollar sign ('$') must be treated as a 
variable reference and validated, unless it is part of an escaped literal dollar sign sequence 
according to section 10.3.3. Each reference must use proper variable name syntax, according to 
section 10.3.1. Each reference must be placed either within a card's text (# PCDATA) or within 
%vdata or %HREF attribute values. Other CDATA attribute values must use escaped literal dollar 
sign as required to prevent the creation of an otherwise valid variable reference. The deck is in 
error if any variable reference uses invalid syntax or is placed in an invalid location. 

Examples of invalid variable use: 

<!-- bad variable syntax --> 
Balance left is $10.00 

<!-- bad placement (in the type attribute) --> 
<do type="x-$ (type) " label= " $type" > 

Example of escaped dollar sign in an attribute of type CDATA: 

<!-- Dollar sign escaped in type attribute --> 
<do type="x-$$ (type) " label= " $type" > 

10.4 Context Restrictions 

User agents may provide users means to reference and navigate to resources independent of the 
current content. For example, user agents may provide bookmarks, a URL input dialog, and so 
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forth. Whenever a user agent navigates to a resource that was not the result of an interaction with 
the content in the current context, the user agent must establish another context for that navigation. 
The user agent may terminate the current context before establishing another one for the new 
navigation attempt. 



Conformance Rules: 




WML- 1 3 Context restrictions 


M 
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1 1 . The Structure of WML Decks 

WML data are structured as a collection of cards. A single collection of cards is referred to as a 
WML deck. Each card contains structured content and navigation specifications. Logically, a user 
navigates through a series of cards, reviews the contents of each, enters requested information, 
makes choices and navigates to another card or returns to a previously visited card. 

11.1 Document Prologue 

A valid WML deck is a valid XML document and therefore must contain an XML declaration and a 
document type declaration (see [XML] for more detail about the definition of a valid document). A 
typical document prologue contains: 
<?xml version="l . 0"?> 

<!DOCTYPE wml PUBLIC " -/ /WAPFORUM/ /DTD WML 1.3//EN" 
"http : //www . wapf orum . org/DTD/wmll3 . dtd" > 

It is an error to omit the prologue. 

11.2 The WML Element 

<! ELEMENT wml ( head?, template?, card+ )> 
< ! ATTLIST wml 

xml:lang NMTOKEN #IMPLIED 

%coreattrs ; 

The wml element defines a deck and encloses all information and cards in the deck. 
Attributes 

xml : lang=nmtoken 



The xml : lang attribute specifies the natural or formal language in which the document is 
written. See section 8.8 for more detail. 



Conformance Rules: 




WML-53 wml 


M 
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11.2.1 A WML Example 

The following is a deck containing two cards, each represented by a card element (see section 
1 1 .5 for information on cards). After loading the deck, a user agent displays the first card. If the 
user activates the DO element, the user agent displays the second card. 

<wml> 
<card> 
<P> 

<do type=" accept "> 

<go href="#card2"/> 
</do> 

Hello world! 

This is the first card. . . 
</p> 
</card> 

<card id="card2"> 
<p> 

This is the second card. 
Goodbye . 
</p> 
</card> 
</wml> 

11.3 The Head Element 

< [ELEMENT head ( access | meta ) +> 
< ! ATTLIST head 
%coreattrs ; 

The head element contains information relating to the deck as a whole, including meta-data and 
access control elements. 

Attributes defined elsewhere 



• id (see section 8.9) 

* class (see section 8.9) 



( onformunce Rules: 




WML-30 bhead 


M 
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1 1 .3.1 The Access Element 

<! ELEMENT access EMPTY> 
< ! ATTLIST access 

domain CDATA #IMPLIED 

path CDATA #IMPLIED 

%coreattrs ; 

The access element specifies access control information for the entire deck. It is an error for a 
deck to contain more than one access element. If a deck does not include an access element, 
access control is disabled. When access control is disabled, cards in any deck can access this deck. 

Attributes 

domain=cdata 
path=cdata 

A deck's domain and path attributes specify which other decks may access it. As the 
user agent navigates from one deck to another, it performs access control checks to 
determine whether the destination deck allows access from the current deck. 

If a deck has a domain and/or path attribute, the referring deck's URI must match the 
values of the attributes. Matching is done as follows: the access domain is suffix -matched 
against the domain name portion of the referring URI and the access path is prefix matched 
against the path portion of the referring URI. 

Domain suffix matching is done using the entire element of each sub-domain and must 
match each element exactly (e.g., www . wapf orum . org shall match wapf orum . org, 
but shall not match forum . org). Path prefix matching is done using entire path 
elements and must match each element exactly (e.g., /X/Y matches path="/X" attribute, 
but does not match path="/XZ" attribute). 

The domain attribute defaults to the current deck's domain. The path attribute defaults to 
the value "/". 

To simplify the development of applications that may not know the absolute path to the 
current deck, the path attribute accepts relative URIs. The user agent converts the relative 
path to an absolute path and then performs prefix matching against the PATH attribute. 

For example, given the following access control attributes: 

domain= "wapf orum . org" 
path="/cbb" 

The following referring URIs would be allowed to go to the deck: 

http: //wapf orum.org/cbb/stocks . cgi 
https : //www. wapf orum. org/ ebb/bonds . cgi 

http : //www. wapf orum.org/cbb/demos/alpha/packages . cgi?x=12 3&y=4 56 
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The following referring URIs would not be allowed to go to the deck: 
http : //www . test . net/ebb 

ht tp : // www . wapf orum . org/ internal/ f oo . wml 
Domain and path follow URL capitalisation rules. 



Attributes defined elsewhere 




• id (see section 8.9) 




• class (see section 8.9) 




C onfoniHince Rules: 




WML-21 access 


M 



11.3.2 The Meta Element 

<! ELEMENT meta EMPTY> 
< ! ATTLIST meta 

http-equiv CDATA #IMPLIED 

name CDATA #IMPLIED 

forua %boolean; "false" 

content CDATA #REQUTRED 

scheme CDATA #IMPLIED 

%coreattrs ; 

The meta element contains generic meta-information relating to the WML deck. Meta- 
information is specified with property names and values. This specification does not define any 
properties, nor does it define how user agents must interpret meta-data. User agents are not required 
to support the meta-data mechanism. 

A meta element must contain exactly one attribute specifying a property name; i.e., exactly one 
from the following set: http-equiv and name. 

Attributes 
name=cdata 

This attribute specifies the property name. The user agent must ignore any meta-data 
named with this attribute. Network servers should not emit WML content containing meta- 
data named with this attribute. 

ht tp-equi v=cdata 

This attribute may be used in place of name and indicates that the property should be 
interpreted as an HTTP header (see [RFC2068]). Meta-data named with this attribute 
should be converted to a WSP or HTTP response header if the content is tokenised before it 
arrives at the user agent. 

f orua= bool ean 

If the value is "false" an intermediate agent MUST remove the "meta" element before the 
document is sent to the client. If the value is "true" the meta data of the element MUST be 
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delivered to the user-agent. The method of delivery may vary. For example, http-equiv 
meta-data may be delivered using HTTP or WSP headers. 

content=cdata 

This attribute specifies the property value. 

scheme= cdata 

This attribute specifies a form or structure that may be used to interpret the property value. 
Scheme values vary depending on the type of meta-data. 



Attributes defined elsewhere 

• id (see section 8.9) 

* class (see section 8.9) 



C 'onforminice Rules: 






WML-34 


meta 


0 


WML-67 


A meta element must not contain more than one attribute of 
name and http-equiv 


M 


WML-72 


A meta element must not contain more than one attribute of 
name and http-equiv 


0 



1 1 .4 The Template Element 

<! ENTITY % navelmts "do | onevent " > 
<! ELEMENT template ( %navelmts ; ) * > 
< ! ATTLIST template 

%cardev; 

%coreattrs ; 

The template element declares a template for cards in the deck. Event bindings specified in the 
template element (e.g., do or onevent) apply to all cards in the deck. Specifying an event 
binding in the template element is equivalent to specifying it in every card element. A card 
element may override the behaviour specified in the template element. In particular: 

• A do element specified in the template element may be overridden in individual cards if 
both elements have the same name attribute value. See section 9.6 for more information. 

• Intrinsic event bindings specified in the template element may be overridden by the 
specification of an event binding in a card element. See section 9.6 for more information. 

See section 1 1.5.1 for the definition of the card-level intrinsic events (the cardev entity). 



© Copyright Wireless Application Protocol Forum.Ltd, 1998, 1999, 2000. 

All rights reserved 



WAP-191-WML, 19 February 2000 



Page 54 (110) 



Attributes defined elsewhere 

• id (see section 8.9) 

• class (see section 8.9) 

• onenterf orward (see section 11.5.1) 

• onenterbackward (see section 11.5.1) 

• ontimer (see section 11.5.1) 



C 'onformancc Rules: 




WML-47 template 


M 


11.5 The Card Element 




A WML deck contains a collection of cards. Each card can contain a variety of content. The user's 
interaction with the card depends on the type of content the card contains and how the content is 
rendered by the user agent. 


C onfoniHince Rules: 




WML-25 card 


M 


11.5.1 Card Intrinsic Events 




<! ENTITY % cardev 
"onenterf orward %HREF; 
onenterbackward %HREF; 
ontimer %HREF ; 


#IMPLIED 
#IMPLIED 
#IMPLIED" 


The following attributes are available in the card and template elements. 



Attributes 

onenterf orvrard=HREF 

The onenterf orward event occurs when the user causes the user agent to navigate into 
a card using a go task. 

onenterbackward=HR.EF 

The onenterbackward event occurs when the user causes the user agent to navigate 
into a card using a prev task. 

ontimer=HRE'F 

The ontimer event occurs when a timer expires. 
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11.5.2 The Card Element 



<! ELEMENT card (onevent 
< ! ATTLIST card 
title 

newcontext 
ordered 
xml : lang 
%cardev; 
%coreattrs 



%vdata; 
%boolean; 
%boolean; 
NMTOKEN 



?, (do | p 

#IMPLIED 
"false" 
"true" 
#IMPLIED 



The card element is a container of text and input elements that is sufficiently flexible to allow 
presentation and layout in a wide variety of devices, with a wide variety of display and input 
characteristics. The card element indicates the general layout and required input fields, but does 
not overly constrain the user agent implementation in the areas of layout or user input. For 
example, a card can be presented as a single page on a large-screen device and as a series of 
smaller pages on a small-screen device. 



A card can contain markup, input fields and elements indicating the structure of the card. The 
order of elements in the card is significant and should be respected by the user agent. A card's id 
may be used as a fragment anchor. See section 5.2 for more information. 

Attributes 
title=vdata 

The title attribute specifies advisory information about the card. The title may be 
rendered in a variety of ways by the user agent (e.g., suggested bookmark name, pop-up 
tooltip, etc.). 

newcontext =boolean 

This attribute indicates that the current browser context should be re-initialised upon entry 
to this card. See section 10.2 for more information. 

ordered=Jboo!ean 

This attribute specifies a hint to the user agent about the organisation of the card content. 
This hint may be used to organise the content presentation or to otherwise influence layout 
of the card. 



• ordered= "true " - the card is naturally organised as a linear sequence of field 

elements, e.g., a set of questions or fields which are naturally handled by the user in the 
order in which they are specified in the group. This style is best for short forms in 
which no fields are optional (e.g., sending an email message requires a To : address, a 
subject and a message, and they are logically specified in this order). 

It is expected that in small-screen devices, ordered groups may be presented as a 
sequence of screens, with a screen flip in between each field or fieldset. Other user 
agents may elect to present all fields simultaneously. 



© Copyright Wireless Application Protocol Forum.Ltd, 1998, 1999, 2000. 

All rights reserved 



WAP-191-WML, 19 February 2000 



Page 56 (110) 



• ordered= "false" - the card is a collection of field elements without a natural order. 
This is useful for collections of fields containing optional or unordered components or 
simple record data where the user is updating individual input fields. 

It is expected that in small-screen devices, unordered groups may be presented by using 
a hierarchical or tree organisation. In these types of presentation, the tit le attribute 
of each field and fieldset may be used to define the name presented to the user in the 
top-level summary card. A user agent may organise an unordered collection of elements 
in an ordered fashion. 

The user agent may interpret the ordered attribute in a manner appropriate to its device 
capabilities (e.g., screen size or input device). In addition, the user agent should adopt user 
interface conventions for handling the editing of input elements in a manner that best suits 
the device's input model. 

For example, a phone-class device displaying a card with ordered= "false" may use 
a softkey or button to select individual fields for editing or viewing. A PDA-class device 
might create soft buttons on demand, or simply present all fields on the screen for direct 
manipulation. 

On devices with limited display capabilities, it is often necessary to insert screen flips or 
other user-interface transitions between fields. When this is done, the user agent needs to 
decide on the proper boundary between fields. User agents may use the following heuristic 
for determining the choice of a screen flip location: 

• fieldset defines a logical boundary between fields. 

• Fields (e.g., input) may be individually displayed. When this is done, the line of 
markup (flow) immediately preceding the field should be treated as a field prompt and 
displayed with the input element. The table must be treated differently than input 
and select. The user agent must insert a line break before each table element, 
except when it is the first non-whitespace markup in a card. The user agent must insert 
a line break after each table element, except when it is the final element in a card. 

Attributes defined elsewhere 

• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 

• onenterf orward (see section 1 1.5.1) 

• onenterbackward (see section 11.5.1) 

• ontimer (see section 1 1.5.1) 
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11.5.2.1 A Card Example 

The following is an example of a simple card element embedded within a WML deck. The card 
contains text, which is displayed by the user agent. In addition, the example demonstrates the use 
of a simple DO element, defined at the deck level. 

<wml> 

<template> 

<do type=" accept" label="Exit"> 

<prev/> 
</do> 
</template> 
<card> 
<p> 

Hello World! 
</p> 
</card> 
</wml> 

1 1 .6 Control Elements 

11.6.1 The Tabindex Attribute 

Attributes 

tabindex=numJber 

This attribute specifies the tabbing position of the current element. The tabbing position 
indicates the relative order in which elements are traversed when tabbing within a single 
WML card. A numerically greater tabindex value indicates an element that is later in the 
tab sequence than an element with a numerically lesser tabindex value. 

Each input element (i.e., input and select) in a card is assigned a position in the card's 
tab sequence. In addition, the user agent may assign a tab position to other elements. The 
tabindex attribute indicates the tab position of a given element. Elements that are not 
designated with an author-specified tab position may be assigned one by the user agent. 
User agent specified tab positions must be later in the tab sequence than any author- 
specified tab positions. 

Tabbing is a navigational accelerator and is optional for all user agents. Authors must not 
assume that a user agent implements tabbing. 

11.6.2 Select Lists 

Select lists are an input element that specifies a list of options for the user to choose from. Single 
and multiple choice lists are supported. 
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11.6.2.1 The Select Element 

[ELEMENT select (optgroup | option) + 



! ATTLIST select 



title 

name 

value 

iname 

ivalue 

multiple 

tabindex 

xml : lang 

%coreattrs ; 



%vdata; 

NMTOKEN 

%vdata; 

NMTOKEN 

%vdata; 

%boolean; 

% number ; 

NMTOKEN 



#IMPLIED 

#IMPLIED 

#IMPLIED 

#IMPLIED 

#IMPLIED 

"false" 

#IMPLIED 

#IMPLIED 



The select element lets users pick from a list of options. Each option is specified by an option 
element. Each option element may have one line of formatted text (which may be wrapped or 
truncated by the user agent if too long). Option elements may be organised into hierarchical 
groups using the optgroup element. 

Attributes 

multiple=jboo!ean 

This attribute indicates that the select list should accept multiple selections. When not set, 
the select list should only accept a single selected option. 

name=nmtoken 
value=vdata 

This name attribute indicates the name of the variable to set with the result of the selection. 
The variable is set to the string value of the chosen option element, which is specified 
with the value attribute. The name variable's value is used to pre-select options in the 
select list. 



The value attribute indicates the default value of the variable named in the name 
attribute. When the element is displayed, and the variable named in the name attribute is 
not set, the name variable may be assigned the value specified in the value attribute, 
depending on the values defined in iname and ivalue. If the name variable already 
contains a value, the value attribute is ignored. Any application of the default value is 
done before the list is pre-selected with the value of the name variable. 

If this element allows the selection of multiple options, the result of the user's choice is a list 
of all selected values, separated by the semicolon character. The name variable is set with 
this result. In addition, the value attribute is interpreted as a semicolon-separated list of 
pre-selected options. 

i name = nm t c*e.n 
ivalue=vdata 

The iname attribute indicates the name of the variable to be set with the index result of the 
selection. The index result is the position of the currently selected option in the select 
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list. An index of zero indicates that no option is selected. Index numbering begins at one 
and increases monotonically. 

The i value attribute indicates the default-selected option element. When the element is 
displayed, if the variable named in the iname attribute is not set, it is assigned the default- 
selected entry. If the variable already contains a value, the ivalue attribute is ignored. If 
the iname attribute is not specified, the ivalue value is applied every time the element is 
displayed. 

If this element allows the selection of multiple options, the index result of the user's choice 
is a list of the indices of all the selected options, separated by the semicolon character (e.g., 
"1;2"). The iname variable is set with this result. In addition, the ivalue attribute is 
interpreted as a semicolon-separated list of pre-selected options (e.g., "1;4"). 

title=vdata 

This attribute specifies a title for this element, which may be used in the presentation of this 
object. 

Attributes defined elsewhere 

• xml : lang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 

• t abindex (see section 1 1 .6. 1) 

On entry into a card containing a select element, the user agent must select the initial option 
element's options and update associated variables (specified by the name or iname attributes) in 
the following manner. If the card contains multiple select elements, or input elements along 
with select elements, the initialisation must take place in the order that the elements appear in 
the card. 

Note that values are a semicolon delimited list of values when multiple = "true " , but are 
otherwise treated as a single value (even if they contain semicolons). In addition, the default option 
index is an aggregate value (a list) when mul t iple= "true " and is otherwise a single index. 

The selection of initial option elements includes an operation named validate. This operates on a 
value, and determines if that value is a legal option index (or indices when mul t iple= "true "). 
The operation consists of the following steps: 

1 . Remove all non-integer indices from the value. 

2. Remove all out-of-range indices from the value, where out-of-range is defined as any index 
with a value greater than the number of options in the select or with a value less than one. 

3. Remove duplicate indices 

Note that an invalid index will result in an empty value. 
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The selection of the initial option elements consists of the following steps: 
Step 1 - the default option index is determined using iname and ivalue: 

• IF the iname attribute is specified AND names a variable that is set, THEN the default option 
index is the validated value of that variable. 

• IF the default option index is empty AND the ivalue attribute is specified, THEN the default 
option index is the validated attribute value. 

• IF the default option index is empty, AND the name attribute is specified AND the name 
attribute names a variable that is set, THEN for each value in the name variable that is present 
as a value in the select ' s option elements, the index of the first option element 
containing that value is added to the default index if that index has not been previously added. 

• IF the default option index is empty AND the value attribute is specified THEN for each 
value in the value attribute that is present as a value in the select ' s option elements, the 
index of the first option element containing that value is added to the default index if that 
index has not been previously added. 

• IF the default option index is empty AND the select is a multi-choice, THEN the default 
option index is set to zero. 

• IF the default option index is empty AND the select is a single-choice, THEN the default 
option index is set to one. 

Step 2 - initialise variables 

• IF the name attribute is specified AND the select is a single-choice element, THEN the 
named variable is set with the value of the value attribute on the option element at the 
default option index. 

• Else, IF the name attribute is specified and the select is a multiple-choice element, THEN 
for each index greater than zero, the value of the value attribute on the option element at 
the index is added to the name variable. 

• IF the iname attribute is specified, THEN the named variable is set with the default option 
index. 

Step 3 - pre-select option(s) specified by the default option index 

• Deselect all options 

• For each index greater than zero, select the option specified by the index. 
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When the user selects or deselects one or more option elements, the name and iname variables 
are updated with the option's value and index. The name is unset if all selected option elements 
contain an empty value attribute. However, in all cases, the user agent must not exhibit display 
side effects as a result of updating name and iname variables, except when there is an explicit 
refresh task (see section 9.4.3). The user agent must update name and iname variables (if 
specified) for each select element in the card before each and all task invocations according to 
steps 1 and 2 above. 

Multiple choice selection lists result in a value that is a semicolon delimited list (e.g., 
" dog ; cat " )• This is not an ordered list and the user agent is free to construct the list in any order 
that is convenient. Authors must not rely on a particular value ordering. The user agent must 
ensure that the iname result contains no duplicate index values. The name result must contain 
duplicate values in the situation where multiple selected option elements have the same value. 
The name result must not contain empty values (e.g., " cat ; ; dog " is illegal). 



C 'onformancc Rules: 




WML-43 select 


M 



11.6.2.2 The Option Element 



< [ELEMENT option (# PCDATA | onevent)*> 
< ! ATTLIST option 

value %vdata; #IMPLIED 

title %vdata; #IMPLIED 

onpick %HREF; #IMPLIED 

xml:lang NMTOKEN #IMPLIED 

%coreattrs ; 

This element specifies a single choice option inaselect element. 

Attributes 
value=vdata 

The value attribute specifies the value to be used when setting the name variable. When 
the user selects this option, the resulting value specified in the value attribute is used to 
set the select element's name variable. 

The value attribute may contain variable references, which are evaluated before the name 
variable is set. 

title=vdata 

This attribute specifies a title for this element, which may be used in the presentation of this 
object. 

onpick=HRE'F 

The onpick event occurs when the user selects or deselects this option. A multiple- 
selection option list generates an onpick event whenever the user selects or deselects this 
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option. A single-selection option list generates an onpick event when the user selects this 
option, i.e., no event is generated for the de-selection of any previously selected option. 

Attributes defined elsewhere 

• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 



C 'onforminice Rules: 




WML-41 option 


M 



11.6.2.3 The Optgroup Element 



<! ELEMENT optgroup (optgroup | option) + > 
< ! ATTLIST optgroup 

title %vdata; #IMPLIED 

xmlrlang NMTOKEN #IMPLIED 

%coreattrs ; 

The optgroup element allows the author to group related option elements into a hierarchy. 
Within a hierarchy, all leaf elements must be option elements (i.e., it is an error to build a 
hierarchy that contains a leaf optgroup element. The user agent may use this hierarchy to 
facilitate layout and presentation on a wide variety of devices. The user agent may choose not to 
build a hierarchy effectively ignoring optgroup elements. However, in all cases, the user agent 
must continue processes all the element's children. 

Attributes 
title=vdata 

This attribute specifies a title for this element, which may be used in the presentation of this 
object. 

Attributes defined elsewhere 

• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 



C onfoniHince Rules: 




WML-40 optgroup 


0 
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11.6.2.4 Select list examples 

In this example, a simple single-choice select list is specified. If the user were to choose the "Dog" 
option, the variable "X" would be set to a value of "D". 

<wml> 
<card> 
<P> 

Please choose your favourite animal: 
<select name="X"> 

<option value= "D" >Dog</option> 
<option value="C">Cat</option> 
</select> 
</p> 
</card> 
</wml> 

In this example, a single choice select list is specified. If the user were to choose the "Cat" option, 
the variable "I" would be set to a value of "2". In addition, the "Dog" option would be pre-selected 
if the "I" variable had not been previously set. 

<wml> 
<card> 
<p> 

Please choose your favourite animal: 
<select iname="I" ivalue="l"> 
<option value= "D" >Dog</option> 
<option value= "C" >Cat</option> 
</select> 
</p> 
</card> 
</wml> 
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In this example, a multiple-choice list is specified. If the user were to choose the "Cat" and "Horse" 
options, the variable "X" would be set to "C;H" and the variable "I" would be set to "2;3". In 
addition, the "Dog" and "Cat" options would be pre-selected if the variable "I" had not been 
previously set. 

<wml> 
<card> 
<P> 

Please choose <i>all</i> of your favourite animals: 
<select name="X" iname="I" ivalue= " 1 ; 2 " multiple="true"> 
<option value= "D" >Dog</option> 
<option value="C">Cat</option> 
<option value= "H" >Horse</option> 
</select> 
</p> 
</card> 
</wml> 

In this example, a single choice select list is specified. The variable "F" would be set to the value of 
"S" if the user chooses the first option. The second option is always pre-selected, regardless of the 
value of the variable "F". 

<wml> 
<card> 
<p> 

Please choose from the menu: 
<select name="F" ivalue="2"> 

<option value= "S" >Sandwich</option> 
<option value= "D" >Drink</option> 
</select> 
</p> 
</card> 
</wml> 

In this example, the use of the onpick intrinsic event is demonstrated. If the user selects the 
second option, a go will be performed to the "/morehelp . wml" URL. 

<wml> 
<card> 
<p> 

Select type of help: 
<select> 

<opt ion onpick= " /help . wml " >Help</opt ion> 
<option onpick=" /morehelp. wml " >More Help</option> 
</select> 
</p> 
</card> 
</wml> 
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In this example, if the name variable is set to the value " 1 ; 2 " , the third option will be pre- 
selected. This demonstrates that values containing semicolons are treated as a single value in a 
single-choice selection element. 

<wml> 
<card> 
<P> 

Select one: 
<select name="K"> 

<option value="l">One</option> 
<option value="2">Two</option> 
<option value= " 1 ; 2 " >Both</option> 
</select> 
</p> 
</card> 
</wml> 

11.6.3 The Input Element 



<! ELEMENT input EMPTY> 
< ! ATTLIST input 



name 


NMTOKEN 


#REQUTRED 


type 


(text password) 


"text" 


value 


%vdata ; 


#IMPLIED 


format 


CDATA 


#IMPLIED 


emptyok 


%boolean; 


#IMPLIED 


size 


% number ; 


#IMPLIED 


maxlength 


% number ; 


#IMPLIED 


tabindex 


% number ; 


#IMPLIED 


title 


%vdata; 


#IMPLIED 


accesskey 


%vdata; 


#IMPLIED 


xml : lang 


NMTOKEN 


#IMPLIED 


%coreattrs 







The input element specifies a text entry object. The user's input is constrained by the 
combination of the optional format and emptyok attributes. If a valid input mask is bound to an 
input object, the user agent must ensure that any value collected by the entry object conforms to the 
bound input mask when the user attempts to commit the value. If the input collected does not 
conform to the input mask, the user agent must not commit that input and must notify the user that 
the input was rejected and allow the user to resubmit new input. In this case, the variable specified 
in the name attribute must not be modified from its original value. The user agent may validate 
each character against the input mask as the user enters it. 

All input objects that represent the input elements (and select elements, if any) within the card 
must be initialised when the card is rendered, and the initialisation must take place in the order that 
the elements appear in the card. The initialisation must be done with the following two steps: 

• The user agent decides the initial value from the name and value attributes, and if needed 
sets or unsets the variable specified in the name attribute (see attributes description below). 
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• The user agent pre-loads the initial value into the input object (e.g., renders the initial 
value into the text entry object). 

If the user clears the initial value of an input object and attempts to commit that input, it is 
regarded as a submission of an empty string. The user agent must accept the submission of an 
empty string only when the input mask allows an empty string. 

Attributes 

name=nmtoken 
value=vdata 

The name attribute specifies the name of the variable to set with the result of the user's text 
input. The name variable's value is used as the initial value of the input object. If the 
name variable contains a value that does not conform to the input mask, the user agent must 
unset the variable and attempt to initialise the variable with the value attribute. 

The value attribute indicates the default value of the variable named in the name 
attribute. When the element is displayed and the variable named in the name attribute is 
not set, the name variable is assigned the value specified in the value attribute. If the 
name variable already contains a value, the value attribute is ignored. If the value 
attribute specifies a value that does not conform to the input mask specified by the format 
attribute, the user agent must ignore the value attribute. In the case where no valid value 
can be established, the name variable is left unset and the input object must be initialised 
with the empty string. 

type= (text {password) 

This attribute specifies the type of text- input area. The default type is text. The following 
values are allowed: 

• text - a text entry control. User agents should echo the input in a manner appropriate 
to the user agent and the input mask. If the submitted value conforms to an existing 
input mask, the user agent must store that input unaltered and in its entirety in the 
variable named in the name attribute. For example, the user agent must not trim the 
input by removing leading or trailing white space from the input. If the variable named 
by the name attribute is unset, the user agent should echo an empty string in an 
appropriate manner. 

• password - a text entry control. Input of each character should be echoed in an 
obscured or illegible form in a manner appropriate to the user agent. For example, 
visual user agents may elect to display an asterisk in place of a character entered by the 
user. Typically, the password input mode is indicated for password entry or other 
private data. Note that Password input is not secure and should not be depended on 
for critical applications. Similar to a text type, if the submitted value conforms to an 
existing input mask, the user agent must store input unaltered and in its entirety in the 
variable named in the name attribute. User agents should not obscure non-formatting 
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characters of the input mask. If the variable named by the name attribute is unset, the 
user agent should echo an empty string in an appropriate manner. 

f ormat= cdata 

The format attribute specifies an input mask for user input entries. The string consists of 
mask control characters and static text that is displayed in the input area. The user agent 
may use the format mask to facilitate accelerated data input (e.g. the user agent may change 
its input mode according to the format code of the current position of the input cursor). An 
input mask is only valid when it contains only legal format codes and static text. User 
agents must ignore invalid masks. 

Character categories are as defined by [Unicode]: 

• "Letter" refers to character categories Lu, LI, Lm, and Lo. 

• "Uppercase letter" refers to character categories Lu and Lm. 

• "Lowercase letter" refers to character categories LI and Lm. 

• "Numeric character" refers to the character category Nd. 

• "Punctuation" refers to character categories Pc, Pd, Ps, Pe, and Po. 

• "Symbol" refers to character categories Sm, Sc, Sk, and So. 

User agents need only be capable of displaying and accepting the subsets of the above sets 
that are appropriate for all languages that they support. However, all user agents must 
support ASCII graphic characters of the Unicode Basic Latin block (U+0020 - U+007E). 

For a given input element, user agents may choose to restrict the set of allowable characters 
to those appropriate for the current language(s). 

The current languages are the superset of: 

• the current language of the WML deck, plus 

• the user agent's accept language(s), plus 

• the user agent's interface language. 

In caseless languages, format codes distinguishing between upper and lowercase are 
equivalent. 

The format control characters specify the data format expected to be entered by the user. 
The default format is "*M". The format codes are: 

A entry of any uppercase letter, symbol, or punctuation character. Numeric 
characters are excluded. 
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a entry of any lowercase letter, symbol, or punctuation character. Numeric 
characters are excluded. 

N entry of any numeric character. 

n entry of any numeric, symbol, or punctuation character. 

X entry of any uppercase letter, numeric character, symbol, or punctuation 
character. 

x entry of any lowercase letter, numeric character, symbol, or punctuation 
character. 

M entry of any character valid in the current languages, including any letter, 

numeric, symbol, or punctuation character. If the language supports case and the 
hardware supports both upper and lower case entry, the user agent may choose to 
default to uppercase entry mode but must allow entry of any character. 

m entry of any character valid in the current languages, including any letter, 

numeric, symbol, or punctuation character. If the language supports case and the 
hardware supports both upper and lower case entry, the user agent may choose to 
default to lowercase entry mode but must allow entry of any character. 

*/ entry of any number of characters; f is one of the above format codes and 

specifies what kind of characters can be entered. Note: This format may only be 
specified once and must appear at the end of the format string. 

nf entry of up to n characters where n is from 1 to 9; f is one of the above format 
codes (other than * f format code) and specifies what kind of characters can be 
entered. Note: This format may only be specified once and must appear at the 
end of the format string. 

\c display the next character, c, in the entry field; allows escaping of the format 

codes as well as introducing non-formatting characters so they can be displayed 
in the entry area. Escaped characters are considered part of the input's value, and 
must be preserved by the user agent. For example, the stored value of the input 
"12345-123" havingamask "NNNNN\-3N" is "12345-123" and not 
"12345123". Similarly, if the value of the variable named by the name 
attribute is "1234 5123" and the mask is " NNNNN\ - 3N " , the user agent must 
unset the variable since it does not conform to the mask. 

emp tyok= bool ean 

The emptyok attribute indicates whether this input element accepts empty input or not. 
If emptyok is true, input is not required even if the format mask would otherwise require 
it. If emptyok is false, input is required even if the format mast would otherwise not 
require it. 
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<." / > <!-- implied: format = "*M" emptyok=" true" 

<." f ormat = " *M" /> <!-- implied: emptyok=" true" 

<." emptyok="true"/> <!-- implied: format = "*M" 

<." emptyok="true" f ormat = "M*M" /> 
<." emptyok="true" f ormat = " *M" /> 



If the author does not explicitly specify the emptyok attribute, the format attribute fully 
defines the input requirement. The implied value of the emptyok attribute is "true" when 
the format attribute allows empty input (i.e., the format mask is implied or a "*f ' format 
code). Otherwise, the implied value of the attribute is "false". 

Whether or not input is required, any input given must match the format specification. 
For the following input elements, input is required: 

<input name="x" f ormat="M*M" /> <!-- implied: emptyok=" false" --> 

<input name="x" emptyok=" false" /> <!-- implied: format="*M" --> 

<input name="x" emptyok=" false" f ormat="M*M" /> 
<input name="x" emptyok=" false" f ormat=" *M" /> 

For the following input elements, input is not required: 

< input name= 
< input name= 
< input name= 
< input name= 
< input name= 
size=number 

This attribute specifies the width, in characters, of the text-input area. The user agent may 
ignore this attribute. 

maxlength=numJber 

This attribute specifies the maximum number of characters that can be entered by the user in 
the text-entry area. The default value for this attribute is an unlimited number of characters. 

title=vdata 

This attribute specifies a title for this element, which may be used in the presentation of this 
object. 

Attributes defined elsewhere 

• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 

• t abindex (see section 1 1 .6. 1) 
accesskey (see section 9 



Conformance Rules: 




WML-33 input 


M 


11.6.3.1 Input Element Examples 



In this example, an input element is specified. This element accepts any characters and displays 
the input to the user in a human-readable form. The maximum number of character entered is 32 
and the resulting input is assigned to the variable named X. 
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<input name="X" type="text" maxlength= " 32 " /> 
The following example requests input from the user and assigns the resulting input to the variable 
name. The text field has a default value of "Robert". 

< input name= "NAME" type="text" value= "Robert "/> 

The following example is a card that prompts the user for a first name, last name and age. 

<card> 
<p> 

First name: <input type="text" name="f irst"/xbr/> 
Last name: <input type="text" name="last"/xbr/> 
Age: <input type="text" name="age" format="*N"/> 
</p> 
</card> 

11.6.4 The Fieldset Element 

< [ELEMENT fieldset (%fields ; | do)* > 
< ! ATTLIST fieldset 

title %vdata; #IMPLIED 

xml:lang NMTOKEN #IMPLIED 

%coreattrs ; 

The fieldset element allows the grouping of related fields and text. This grouping provides 
information to the user agent, allowing the optimising of layout and navigation. Fieldset 
elements may nest, providing the user with a means of specifying behaviour across a wide variety 
of devices. It is an error to include empty fieldset elements. See section 1 1.5.2 for information 
on how the fieldset element may influence layout and navigation. If a user agent chooses to 
discard fieldsets, it must continue to process all its children. 

Attributes 
title=vdata 

This attribute specifies a title for this element, which may be used in the presentation of this 
object. 

Attributes defined elsewhere 



• xml:lang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 



( onformunce Rules: 




WML-28 fieldset 


O 
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11.6.4.1 Fieldset Element Examples 

The following example specifies a WML deck that requests basic identity and personal information 
from the user. It is separated into multiple field sets, indicating the preferred field grouping to the 
user agent. 

<wml> 
<card> 
<P> 

<do type=" accept "> 

<go href = " / submit ?f=$ (f name) & 1=$ (lname) & s=$ (sex) & a=$ (age) " /> 
</do> 

<fieldset title= "Name " > 
First name: 

< input type="text" name 
<br/> 

Last name: 

< input type="text" name 
</f ieldset> 

<fieldset title= " Inf o" > 
<select name="sex"> 

< opt ion value= " F" >Female< /option> 

< opt ion value= "M" >Male</option> 
</select> 
<br/> 

Age: <input type="text" name="age" f ormat= " *N" /> 
</f ieldset> 
</p> 
</card> 
</wml> 

1 1 .7 The Timer Element 

<! ELEMENT timer EMPTY> 
< ! ATTLIST timer 

name NMTOKEN 
value %vdata; 
%coreattrs ; 

The timer element declares a card timer, which exposes a means of processing inactivity or idle 
time. The timer is initialised and started at card entry and is stopped when the card is exited. Card 
entry is any task or user action that results in the card being activated, for example, navigating into 
the card. Card exit is defined as the execution of any task (see sections 9.5 and 12.5). The value of 
a timer will decrement from the initial value, triggering the delivery of an ont imer intrinsic event 
on transition from a value of one to zero. If the user has not exited the card at the time of timer 
expiration, an ont imer intrinsic event is delivered to the card. 

Timer resolution is implementation dependent. The interaction of the timer with the user agent's 
user interface and other time-based or asynchronous device functionality is implementation 
dependent. It is an error to have more than one timer element in a card. 
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The timer timeout value is specified in units of one-tenth (1/10) of a second. The author should 
not expect a particular timer resolution and should provide the user with another means to invoke a 
timer's task. If the value of the timeout is not a positive integral number, the user agent must ignore 
the timer element. A timeout value of zero (0) disables the timer. 

Invoking a refresh task is considered an exit. The task stops the timer, commits it's value to the 
context, and updates the user agent accordingly. Completion of the refresh task is considered an 
entry to the card. At that time, the timer must resume. 

Attributes 
name=nmtoken 

The name attribute specifies the name of the variable to be set with the value of the timer. 
The name variable's value is used to set the timeout period upon timer initialisation. The 
variable named by the name attribute will be set with the current timer value when the card 
is exited or when the timer expires. For example, if the timer expires, the name variable is 
set to a value of "0". 

value=vdata 

The value attribute indicates the default value of the variable named in the name 
attribute. When the timer is initialised and the variable named in the name attribute is not 
set, the name variable is assigned the value specified in the value attribute. If the name 
variable already contains a value, the value attribute is ignored. If the name attribute is 
not specified, the timeout is always initialised to the value specified in the value attribute. 

Attributes defined elsewhere 



• id (see section 8.9) 

* class (see section 8.9) 



( 'onformunce Rules: 




WML-48 timer 


M 



11.7.1 Timer Example 



The following deck will display a text message for approximately 10 seconds and will then go to 
the URL next. 

<wml> 

<card ontimer="/next"> 
<timer value="100"/> 
<P> 

Hello World! 
</p> 
</card> 
</wml> 
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The same example could be implemented as: 

<wml> 
<card> 

<onevent type="ontimer " > 

<go href ="/next"/> 
</onevent> 

<timer value="100"/> 
<P> 

Hello World! 
</p> 
</card> 
</wml> 

The following example illustrates how a timer can initialise and reuse a counter. Each time the 
card is entered, the timer is reset to value of the variable t. If t is not set, the timer is set to a value 
of 5 seconds. 

<wml> 

<card ontimer="/next » > 

< timer name="t" value="50"/> 
<P> 

Hello World! 
</p> 
</card> 
</wml> 

1 1 .8 Text 

This section defines the elements and constructs related to text. 

11.8.1 White Space 

WML white space and line break handling is based on [XML] and assumes the default XML white 
space handling rules for text. The WML user agent ignores all insignificant white space in 
elements and attribute values, as defined by the XML specification. White space immediately 
before and after an element is ignored. In addition, all other sequences of white space must be 
compressed into a single inter-word space. 

User agents should treat inter- word spaces in a locale-dependent manner, as different written 
languages treat inter-word spacing in different ways. 

11.8.2 Emphasis 

< [ELEMENT em (%flow;)*> 
< ! ATTLIST em 

xml:lang NMTOKEN #IMPLIED 

%coreattrs ; 
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c ! ELEMENT strong (%flow;)*> 
c ! ATTLIST strong 

xml: lang NMTOKEN 

%coreattrs ; 



c! ELEMENT i 
c ! ATTLIST i 
xml : lang 
%coreattrs ; 

c [ELEMENT b 
c ! ATTLIST b 
xml : lang 
%coreattrs ; 

c [ELEMENT u 
c ! ATTLIST u 
xml : lang 
%coreattrs ; 

c [ELEMENT big 
c ! ATTLIST big 
xml : lang 
%coreattrs ; 



(%flow; ) *> 
NMTOKEN 

(%flow; ) *> 
NMTOKEN 

(%flow; ) *> 
NMTOKEN 

(%flow; ) *> 
NMTOKEN 



c [ELEMENT small (%flow;)*> 
c ! ATTLIST small 

xml: lang NMTOKEN 

%coreattrs ; 



The emphasis elements specify text emphasis markup information, 
em: Render with emphasis, 

s t rong: Render with strong emphasis. 

Render with an italic font. 
Render with a bold font. 
Render with underline, 
big: Render with a large font, 

sma 1 1 : Render with a small font. 



Authors should use the strong and em elements where possible. The b, i and u elements should 
not be used except where explicit control over text presentation is required. 

Visual user agents must distinguish emphasised text from non-emphasised text. A user agent 
should do a best effort to distinguish the various forms of emphasised text as described above. It 
should distinguish text that has been emphasised using the em element from that using strong 
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element. User agents may use the same style for strong, b, and big emphasis. It may also use 
the same style for em, i, u, and small emphasis. 

Attributes defined elsewhere 

• xmlrlang (see section 8.8) 

• id (see section 8.9) 
class (see section 8 . 9) 



( onformunce Rules: 






WML-22 


b 


0 


WML-23 


big 


0 


WML-27 


em 


0 


WML-31 


i 


0 


WML-44 


small 


0 


WML-45 


strong 


0 


WML-51 


u 


0 



11.8.3 Paragraphs 



< ! ENTITY % TAlign " (left | right | center) " > 
<! ENTITY % WrapMode " (wrap | nowrap) 

< ! ELEMENT p (%fields ; | do)*> 

< ! ATTLIST p 

align %TAlign; "left" 

mode %WrapMode; #IMPLIED 

xmlrlang NMTOKEN #IMPLIED 
%coreattrs ; 



WML has two line-wrapping modes for visual user agents: breaking (or wrapping) and non- 
breaking (or non- wrapping). The treatment of a line too long to fit on the screen is specified by the 
current line-wrap mode. If mode= "wrap" is specified, the line is word- wrapped onto multiple 
lines. In this case, line breaks should be inserted into a text flow as appropriate for presentation on 
an individual device. If mode= "nowrap" is specified, the line is not automatically wrapped. In 
this case, the user agent must provide a mechanism to view entire non-wrapped lines (e.g., 
horizontal scrolling or some other user-agent-specific mechanism). 

Any inter- word space is a legal line break point. The non-breaking space entity (&nbsp ; or 
&# 1 6 0 ; ) indicates a space that must not be treated as an inter- word space by the user agent. 
Authors should use &nbsp ; to prevent undesired line-breaks. The soft-hyphen character entity 
(­ or &#1 73 ;) indicates a location that may be used by the user agent for a line break. If a 
line break occurs at a soft-hyphen, the user agent must insert a hyphen character (&#4 5 ; ) at the 
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end of the line. In all other operations, the soft-hyphen entity should be ignored. A user agent may 
choose to entirely ignore soft-hyphens when formatting text lines. 

The p element establishes both the line wrap and alignment parameters for a paragraph. If the text 
alignment is not specified, it defaults to left. If the line-wrap mode is not specified, it is identical 
to the line-wrap mode of the previous paragraph in the current card. Empty paragraphs (i.e., an 
empty element or an element with only insignificant white space) should be considered as 
insignificant and ignored by visual user agents. Insignificant paragraphs do not impact line-wrap 
mode. If the first p element in a card does not specify a line-wrap or alignment mode, that mode 
defaults to the initial mode for the card. The user agent must insert a line break into the text flow 
between significant p elements. 

Insignificant paragraphs may be removed before the document is delivered to the user agent. 
Attributes 

align= (left \ right \ center) 

This attribute specifies the text alignment mode for the paragraph. Text can be centre 
aligned, left aligned or right aligned when it is displayed to the user. Left alignment is the 
default alignment mode. If not explicitly specified, the text alignment is set to the default 
alignment. 

mode= (wrap \ nowrap) 

This attribute specifies the line-wrap mode for the paragraph. Wrap specifies breaking text 
mode and nowrap specifies non-breaking text mode. If not explicitly specified, the line- 
wrap mode is identical to the line-wrap mode of the previous paragraph in the text flow of a 
card. The default mode for the first paragraph in a card is wrap. 

Attributes defined elsewhere 

• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 



Conformance Rules: 




WML-36 p 


M 



11.8.4 The Br Element 



< [ELEMENT br EMPTY> 
< ! ATTLIST br 
%coreattrs ; 

The br element establishes the beginning of a new line. The user agent must break the current line 
and continue on the following line. User agents should do best effort to support the br element in 
tables (see section 11.8.7). 
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Attributes defined elsewhere 




• id (see section 8.9) 




• class (see section 8.9) 




C oiiforiiwiict' Ralcsz 




WML-24 br 


M 



11.8.5 The Table Element 



< [ELEMENT table (tr) +> 
< ! ATTLIST table 

title %vdata; 
align CD AT A 

columns %number; 
xml:lang NMTOKEN 
%coreattrs ; 

The table element is used together with the tr and td elements to create sets of aligned columns 
of text and images in a card. Nesting of table elements it not allowed. The table elements 
determine the structure of the columns. The elements separate content into columns, but do not 
specify column or intercolumn widths. The user agent should do its best effort to present the 
information of the table in a manner appropriate to the device. 

Attributes 
title=vdata 

This attribute specifies a title for this element, which may be used in the presentation of this 
object. 

align=cdata 

This attribute specifies the layout of text and images within the columns of a table. A 
column's contents can be centre aligned, left aligned or right aligned when it is rendered to 
the user. The attribute value is interpreted as a non-separated list of alignment designations, 
one for each column. Centre alignment is specified with the value "C", left alignment is 
specified with the value "L", right alignment is specified with the value "R", and default 
alignment is specified with the value "D". Designators are applied to columns as they are 
defined in the content. The first designator in the list applies to the first column, the second 
designator to the second column, and so forth. Default alignment is applied to columns that 
are missing alignment designators or have unrecognised designators. All extra designators 
are ignored. Determining the default alignment is implementation dependent. User agents 
should consider the current language when determining the default alignment and the 
direction of the table. A user agent may use other algorithms to make such decisions. 

columns=numJber 

This required attribute specifies the number of columns for the table. The user agent must 
create a table with exactly the number of columns specified by the attribute value. It is an 
error to specify a value of zero ("0"). 
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If the actual number of columns in a row is less than the value specified by the columns 
attribute, the row must be padded with empty columns effectively as if the user agent 
appended empty td elements to the row. 

If the actual number of columns in a row is greater than the value specified by this attribute, 
the extra columns of the row must be aggregated into the last column such that the row 
contains exactly the number of columns specified. A single inter-word space must be 
inserted between two cells that are being aggregated. 

The presentation of the table is likely to depend on the display characteristics of the device. 
WML does not define how a user agent renders a table. User agents may create aligned 
columns for each table, or it may use a single set of aligned columns for all tables in a card. 
User agents that choose to render a table in a traditional tabular manner should determine 
the width of each column from the maximum width of the text and images in that column to 
ensure the narrowest display width. However, user agents may use fixed width or other 
appropriate layout algorithms instead. User agents that choose to render tables in a 
traditional tabular manner must use a non-zero width gutter to separate each non-empty 
column. 

Attributes defined elsewhere 



• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 



C 'onformancc Rules: 






WML-46 


table 


M 


WML-68 


The number of columns in a table must not be set to zero 


M 


WML-73 


The number of columns in a table must not be set to zero 


0 



11.8.6 The Tr Element 



< [ELEMENT tr (td) +> 
< ! ATTLIST tr 
%coreattrs ; 

The tr element is used as a container to hold a single table row. Table rows may be empty (i.e., all 
cells are empty). Empty table rows are significant and must not be ignored. 

Attributes defined elsewhere 

• id (see section 8.9) 

* class (see section 8.9) 

C 'onformancc Rules: 
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11.8.7 TheTd Element 

<! ELEMENT td ( %text; | %layout; | img | anchor | a )*> 
< ! ATTLIST td 

xml:lang NMTOKEN #IMPLIED 

%coreattrs ; 

The td element is used as a container to hold a single table cell data within a table row. Table data 
cells may be empty. Empty cells are significant, and must not be ignored. The user agent should 
do a best effort to deal with multiple line data cells that may result from using images or line 
breaks. 

Attributes defined elsewhere 



• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 



( oiiforinuitcc Rules: 




W wiL^-Hy lid 


M 


11.8.8 Table Example 




The following example contains a card with a single column group, containing 


two columns and 


three rows. 




<wml> 




<card> 




<P> 




<table columns="2" align="LL"> 




<trxtd>One </tdxtd> Two </tdx/tr> 




<!-- row missing cells --> 




<trxtd>l</tdx/tr> 




<!-- row with too many cells --> 




<trxtd/xtd> B </tdxtd>C<br/>D</tdx/tr> 




</table> 




</p> 




</card> 




</wml> 




An acceptable layout for this card is: 




One Two 




1 




B C 




D 
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11.8.9 The Pre Element 

<! ELEMENT pre " (# PCDATA | a | anchor do | u | br | i | b | era 
strong | input | select )*"> 

< ! ATTLIST pre 

xml: space CDATA #FIXED "preserve" 
%coreattrs ; 

The pre element tells visual user agents that the enclosed text is "preformatted". When handling 
Preformatted text, user agents: 

• May leave white space intact. 

• May render text with a fixed-pitch font. 

• May disable automatic word wrap. 



The user agent must make "best effort" to achieve the requirements above. 



Conformance Rules: 




WML-75 pre 


O 


11.9 Images 




<! ENTITY % IAlign " (top | middle | bottom) " > 


<! ELEMENT img EMPTY> 




< ! ATTLIST img 




alt %vdata ; 


#REQUTRED 


src %HREF; 


#REQUTRED 


localsrc %vdata; 


#IMPLIED 


vspace %length; 


"0" 


hspace %length; 


"0" 


align %IAlign; 


"bottom" 


height %length; 


#IMPLIED 


width %length; 


#IMPLIED 


xml:lang NMTOKEN 


#IMPLIED 


%coreattrs ; 




The img element indicates that 


an image is to be included in the text flow. Image layout is done 


within the context of normal text layout. 


Attributes 




alt=vdata 




This attribute specifies an alternative textual representation for the image. This 


representation is used when the image can not be displayed using any other method (i.e., the 



user agent does not support images, or the image contents can not be found). 
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sr c=HREF 

This attribute specifies the URI for the image. If the browser supports images, it downloads 
the image from the specified URI and renders it when the text is being displayed. 

localsrc=vdata 

This attribute specifies an alternative internal representation for the image. This 
representation is used if it exists; otherwise the image is downloaded from the URI specified 
in the src attribute, i.e., any local src parameter specified takes precedence over the 
image specified in the src parameter. 

vspace= length 
hspace= length 

These attributes specify the amount of white space to be inserted to the left and right 
(hspace) and above and below (vspace) the image. The default value for this attribute is 
zero indicating that no white space should be inserted. If length is specified as a 
percentage value, the space inserted is based on the available horizontal or vertical space. 
These attributes are hints to the user agent and may be ignored. 

align= ( top | middle | bottom) 

This attribute specifies image alignment within the text flow and with respect to the current 
insertion point, align has three possible values: 

• bottom: means that the bottom of the image should be vertically aligned with the 
current baseline. This is the default value. 

• middle: means that the centre of the image should be vertically aligned with the centre 
of the current text line. 

• top: means that the top of the image should be vertically aligned with the top of the 
current text line. 

height = length 
width= length 

These attributes give user agents an idea of the size of an image or object so that they may 
reserve space for it and continue rendering the card while waiting for the image data. User 
agents may scale objects and images to match these values if appropriate. If length is 
specified as a percentage value, the resulting size is based on the available horizontal or 
vertical space, not on the natural size of the image. These attributes are a hint to the user 
agent and may be ignored. 
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Attributes defined elsewhere 

• xmlrlang (see section 8.8) 

• id (see section 8.9) 

• class (see section 8.9) 

Conformance Rules: 

WML-32 img M 



WML 


54 


Display of alt attribute of <img> 


IF NOT WAE- 
GRIM: M 


WML 


55 


Support for vspace hint 


WAE-GRIM:0 


WML 


56 


Support for hspace hint 


WAE-GRIM:0 


WML 


57 


Support for <img> align 


WAE-GRIM:0 


WML 


58 


Support for <img> height 


WAE-GRIM:0 


WML 


59 


Support for <img> width 


WAE-GRIM:0 
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12. User Agent Semantics 

Except where explicitly stated WML does not dictate how a user agent should render or display 
WML content. The user agent is not obligated to perform any particular mapping of elements to 
user interface widgets, and the WML author should not rely on such. 

12.1 Deck Access Control 

The introduction of variables into WML exposes potential security issues that do not exist in other 
markup languages such as HTML. In particular, certain variable state may be considered private by 
the user. While the user may be willing to send a private information to a secure service, an 
insecure or malicious service should not be able to retrieve that information from the user agent by 
other means. 

A conforming WML user agent must implement deck-level access control, including the access 
element and the sendref erer, domain and path attributes. 



A WML author should remove private or sensitive information from the browser context by 
clearing the variables containing this information. 



C onformunce Rules: 




WML- 14 Deck access control 


M 



12.2 Low-Memory Behaviour 



WML is targeted at devices with limited hardware resources, including significant restrictions on 
memory size. It is important that the author have a clear expectation of device behaviour in error 
situations, including those caused by lack of memory. 



( onformunce Rules: 




WML- 15 Low-memory 


0 



12.2.1 Limited History 



The user agent may limit the size of the history stack (i.e., the depth of the historical navigation 
information). In the case of history size exhaustion, the user agent should delete the least-recently- 
used history information. 

It is recommended that all user agents implement a minimum history stack size of ten entries. 
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12.2.2 Limited Browser Context Size 

In some situations, it is possible that the author has defined an excessive number of variables in the 
browser context, leading to memory exhaustion. 

In this situation, the user agent should attempt to acquire additional memory by reclaiming cache 
and history memory as described in sections 12.2. 1 . If this fails and the user agent has exhausted 
all memory, the user should be notified of the error, and the user agent should be reset to a 
predictable user state. For example, the browser may be terminated or the context may be cleared 
and the browser reset to a well-known state. 

12.3 Error Handling 



Conforming user agents must enforce error conditions defined in this specification and must not 
hide errors by attempting to infer author or origin server intent. 



( onf'ormance Rules: 




WML- 16 Error handling 


M 



12.4 Unknown DTD 



A WML deck encoded with an alternate DTD may include elements or attributes that are not 
recognised by certain user agents. In this situation, a user agent should render the deck as if the 
unrecognised tags and attributes were not present. Content contained in unrecognised elements 
should be rendered. 



Conformance Rules: 




WML- 1 7 Unknown DTD handling 


M 



12.5 Reference Processing Behaviour - Inter-card Navigation 



The following process describes the reference model for inter-card traversal in WML. All user 
agents must implement this process, or one that is indistinguishable from it. 



Conformance Rules: 




WML- 1 8 Inter-card navigation 


M 
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12.5.1 The Go Task 

The process of executing a go task comprises the following steps: 

1 . If the originating task contains se tvar elements, the variable name and value in each 
setvar element is converted into a simple string by substituting all referenced variables. The 
resulting collection of variable names and values is stored in temporary memory for later 
processing. See section 10.3.1 for more information on variable substitution. 

2. The target URI is identified and fetched by the user agent. The URI attribute value is converted 
into a simple string by substituting all referenced variables. 

3. The access control parameters for the fetched deck are processed as specified in section 1 1 .3. 1 . 

4. The destination card is located using the fragment name specified in the URI. 

a) If no fragment name was specified as part of the URI, the first card in the deck is the 
destination card. 

b) If a fragment name was identified and a card has a name attribute that is identical to the 
fragment name, then that card is the destination card. 

c) If the fragment name can not be associated with a specific card, the first card in the deck is 
the destination card. 

5. The variable assignments resulting from the processing done in step #1 (the setvar element) 
are applied to the current browser context. 

6. If the destination card contains a newcontext attribute, the current browser context is re- 
initialised as described in section 10.2. 

7. The destination card is pushed onto the history stack. 

8. If the destination card specifies an onenterf orward intrinsic event binding, the task 
associated with the event binding is executed and processing stops. See section 9.10 for more 
information. 

9. If the destination card contains a timer element, the timer is started as specified in section 
11.7. 

10. The destination card is displayed using the current variable state and processing stops. 
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12.5.2 The PrevTask 

The process of executing a prev task comprises the following steps: 

1 . If the originating task contains se tvar elements, the variable name and value in each 
setvar element is converted into a simple string by substituting all referenced variables. The 
resulting collection of variable names and values is stored in temporary memory for later 
processing. See section 10.3.1 for more information on variable substitution. 

2. The target URI is identified and fetched by the user agent. The history stack is popped and the 
target URI is the top of the history stack. If there is no previous card in the history stack, 
processing stops. 

3. The destination card is located using the fragment name specified in the URI. 

a) If no fragment name was specified as part of the URI, the first card in the deck is the 
destination card. 

b) If a fragment name was identified and a card has a name attribute that is identical to the 
fragment name, then that card is the destination card. 

4. The variable assignments resulting from the processing done in step #1 (the setvar element) 
are applied to the current browser context. 

5. If the destination card specifies an onenterbackward intrinsic event binding, the task 
associated with the event binding is executed and processing stops. See section 9.10 for more 
information. 

6. If the destination card contains a timer element, the timer is started as specified in section 
11.7. 

7. The destination card is displayed using the current variable state and processing stops. 

12.5.3 The Noop Task 

No processing is done for a noop task. 

12.5.4 The Refresh Task 

The process of executing a refresh task comprises the following steps: 

1 . For each setvar element, the variable name and value in each setvar element is converted 
into a simple string by substituting all referenced variables. See section 10.3.1 for more 
information on variable substitution. 



2. The variable assignments resulting from the processing done in step #1 (the setvar element) 
are applied to the current browser context. 
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3. If the card contains a timer element, the timer is started as specified in section 1 1.7. 

4. The current card is re-displayed using the current variable state and processing stops. 

12.5.5 Task Execution Failure 

If a task fails to fetch its target URI or the access control restrictions prevent a successful inter-card 
transition, the user agent must notify the user and take the following actions: 

• The invoking card remains the current card. 

• No changes are made to the browser context, including any pending variable assignments or 
newcontext processing. 

• No intrinsic event bindings are executed. 
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13. WML Reference Information 

WML is an application of [XML] version 1.0. 

13.1 Document Identifiers 

13.1.1 SGML Public Identifier 

-//WAPFORUM//DTD WML 1.3//EN 

13.1.2 WML Media Type 

Textual form: 

text /vnd . wap . wml 
Tokenised form: 

applicat ion/vnd . wap . wmlc 
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Wireless Markup Language (WML) Document Type Definition. 
WML is an XML language. Typical usage: 
<?xml version="l . 0"?> 

<!DOCTYPE wml PUBLIC "-/ /WAPFORUM/ /DTD WML 1.3 //EN" 
"http : //www. wapforum.org/DTD/wmll3 .dtd" > 

<wml> 



<! ENTITY % length "CDATA": 



! ENTITY % vdata 



c ! ENTITY % HREF 



"%vdata 



< ! ENTITY % boolean " (true | false) ' 
< ! ENTITY % number "NMT0KEN" > 
<! ENTITY % coreattrs "id ID 

class CDATA 
<! ENTITY % ContentType "%vdata;"> 



[0-9]+ for pixels or [0-9]+"%" for 
percentage length --> 
attribute value possibly containing 
variable references --> 

URI , URL or URN designating a hypertext 
node. May contain variable references -- 

a number, with format [0-9]+ --> 

#IMPLIED 

#IMPLIED"> 

:!-- media type. May contain variable 
references --> 



<! ENTITY % emph "em | strong | b | i | u | big | small "> 
<! ENTITY % layout "br"> 

< ! ENTITY % text " # PCDATA | %emph;"> 

<!-- flow covers "card- level" elements, such as text and images --> 
<! ENTITY % flow "%text; | %layout; | img | anchor | a | table "> 

<!-- Task types --> 

<! ENTITY % task "go | prev | noop | refresh" > 

<!-- Navigation and event elements --> 
<! ENTITY % navelmts "do | onevent " > 



Decks and Cards 



<! ELEMENT wml ( head?, template?, card+ )> 
< ! ATTLIST wml 

xml:lang NMTOKEN #IMPLIED 

%coreattrs ; 



!-- card intrinsic eve: 

! ENTITY % cardev 

"onenterf orward %HREF 
onenterbackward %HREF 
ontimer %HREF 



#IMPLIED 
#IMPLIED 
#IMPLIED" 



<!-- card field types --> 
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ENTITY % fields "%flow; | input | select | fieldset" 
timer?, (do | p | pre)*)> 



[ELEMENT card (onevent 
! ATTLIST card 

title %vdata; 

newcontext %boolean; 

ordered %boolean; 

xml:lang NMTOKEN 

%cardev; 

%coreattrs ; 



#IMPLIED 
"false" 
"true" 
#IMPLIED 



Event Bindings 



< [ELEMENT do (%task;)> 
< ! ATTLIST do 
type 



label 
name 

optional 
xml : lang 
%coreattrs ; 



CDATA 
%vdata; 
NMTOKEN 
%boolean; 
NMTOKEN 



#REQUIRED 

#IMPLIED 

#IMPLIED 

"false" 

#IMPLIED 



[ELEMENT onevent (%task;)> 
! ATTLIST onevent 

type CDATA #REQUTRED 

%coreattrs ; 



!--================ Deck-level declarations ; 

[ELEMENT head ( access | meta ) +> 
! ATTLIST head 
%coreattrs ; 



[ELEMENT template ( %navelmts ; ) * 
! ATTLIST template 

%cardev; 

%coreattrs ; 



[ELEMENT access EMPTY> 
! ATTLIST access 



domain 
path 



CDATA 
CDATA 



%coreattrs ; 



#IMPLIED 
#IMPLIED 



[ELEMENT meta EMPTY> 
! ATTLIST meta 



http-equi- 

name 

f orua 

content 

scheme 



CDATA 

CDATA 

%boolean; 

CDATA 

CDATA 



#IMPLIED 

#IMPLIED 

"false" 

#REQUIRED 

#IMPLIED 
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%coreattrs ; 



Tasks 



< ! ENTITY % cache-control "(no-cache)" > 
<ELEMENT go (postfield | setvar)*> 
< ! ATTLIST go 

href %HREF; #REQUTRED 

sendreferer %boolean; "false" 

method (post | get) "get" 

enctype %ContentType ; 

" appl i cat ion/x- www- form-url encoded" 
cache-control %cache-control ; #IMPLIED 
accept-charset CDATA #IMPLIED 
%coreattrs ; 



[ELEMENT prev (setvar)* 
! ATTLIST prev 
%coreattrs ; 



[ELEMENT refresh (setvar)* 
! ATTLIST refresh 
%coreattrs ; 



[ELEMENT noop EMPTY> 
! ATTLIST noop 
%coreattrs ; 



[ELEMENT postfield EMPTY> 
! ATTLIST postfield 

name %vdata ; #REQUIRED 

value %vdata; #REQUIRED 

%coreattrs ; 



variables 



[ELEMENT setvar EMPTY> 
! ATTLIST setvar 

name %vdata ; #REQUIRED 

value %vdata; #REQUIRED 

%coreattrs ; 



Card Fields : 



[ELEMENT select (optgroup | option) +> 

! ATTLIST select 
title %vdata; #IMPLIED 

name NMTOKEN #IMPLIED 
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value 
iname 

multiple 
tabindex 
xml : lang 
%coreattrs ; 



%vdata ; 

NMTOKEN 

%vdata; 

%boolean; 

% number ; 

NMTOKEN 



#IMPLIED 

#IMPLIED 

#IMPLIED 

"false" 

#IMPLIED 

#IMPLIED 



[ELEMENT optgroup (optgroup | option) + 

! ATTLIST optgroup 
title %vdata; #IMPLIED 

xml: lang NMTOKEN #IMPLIED 
%coreattrs ; 



[ELEMENT option (# PCDATA | onevei 
! ATTLIST option 

value %vdata; #IMPLIED 

title %vdata; #IMPLIED 

onpick %HREF; #IMPLIED 

xml: lang NMTOKEN #IMPLIED 
%coreattrs ; 



[ELEMENT input EMPTY> 
! ATTLIST input 



name 


NMTOKEN 


#REQUTRED 


type 


(text password) 


"text" 


value 


%vdata; 


#IMPLIED 


format 


CDATA 


#IMPLIED 


emptyok 


%boolean; 


#IMPLIED 


size 


% number ; 


#IMPLIED 


maxlength 


% number ; 


#IMPLIED 


tabindex 


% number ; 


#IMPLIED 


title 


%vdata ; 


#IMPLIED 


accesskey 


%vdata ; 


#IMPLIED 


xml : lang 


NMTOKEN 


#IMPLIED 



%coreattrs ; 



[ELEMENT fieldset (%fields ; | do)* > 

! ATTLIST fieldset 
title %vdata; #IMPLIED 

xml: lang NMTOKEN #IMPLIED 

%coreattrs ; 



[ELEMENT timer EMPTY> 

! ATTLIST timer 
name NMTOKEN 
value %vdata; 
%coreattrs ; 



#IMPLIED 
#REQUIRED 
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! ENTITY % IAlign " (top | middle | bottom) " 



[ELEMENT 
! ATTLIST 

alt 

src 

localsrc 
vspace 
hspace 
align 
height 
width 
xml : lang 
%coreatt 



img EMPTY> 
img 

%vdata; 
%HREF; 
%vdata ; 
%length 
%length 
%IAlign 
%length 
%length 
NMTOKEN 

rs ; 



#REQUTRED 
#REQUIRED 
#IMPLIED 



"bottom" 
#IMPLIED 
#IMPLIED 
#IMPLIED 



Anchor 



[ELEMENT anchor ( # PCDATA | br | img 

! ATTLIST anchor 

title %vdata; #IMPLIED 

accesskey %vdata; #IMPLIED 

xml: lang NMTOKEN #IMPLIED 
%coreattrs ; 



go | prev | refresh ) * 



[ELEMENT a ( # PCDATA | br | img )* 



! ATTLIST , 

href %HREF; 

title %vdata; 

accesskey %vdata; 

xml: lang NMTOKEN 
%coreattrs ; 



#REQUIRED 
#IMPLIED 
#IMPLIED 
#IMPLIED 



[ELEMENT table (tr) + 
! ATTLIST table 



title 
align 
columns 
xml : lang 
%coreattrs ; 



%vdata; 
CDATA 
% number ; 
NMTOKEN 



#IMPLIED 
#IMPLIED 
#REQUIRED 
#IMPLIED 



[ELEMENT tr (td) + 
! ATTLIST tr 
%coreattrs ; 



[ELEMENT td ( %text; 
! ATTLIST td 

xml : lang 

Icoreattrs 



%layout; | img | anchor | a )* 
NMTOKEN #IMPLIED 
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Text layout and line breaks 



[ELEMENT em (%flow;)*: 
! ATTLIST em 

xml: lang NMTOKEN 
%coreattrs ; 



[ELEMENT strong (%flow;)* 
! ATTLIST strong 

xml: lang NMTOKEN 

%coreattrs ; 



[ELEMENT b 
! ATTLIST b 
xml : lang 
%coreattrs ; 



[ELEMENT i 
! ATTLIST i 
xml : lang 
%coreattrs ; 



(%flow; ) *: 
NMTOKEN 



[ELEMENT u 
! ATTLIST u 
xml : lang 
%coreattrs ; 



(%flow; ) * 
NMTOKEN 



[ELEMENT big 
! ATTLIST big 
xml : lang 
%coreattrs ; 



<! ELEMENT small 
< ! ATTLIST small 
xml : lang 
%coreattrs ; 



< ! ENTITY % TAlign " (left | right | center) " > 

<! ENTITY % WrapMode " (wrap | nowrap) " > 

< ! ELEMENT p (%fields ; | do)*> 

< ! ATTLIST p 

align %TAlign; "left" 

mode %WrapMode; #IMPLIED 

xml: lang NMTOKEN #IMPLIED 
%coreattrs ; 



<! ELEMENT br EMPTY> 
< ! ATTLIST br 
%coreattrs ; 
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: ! ATTLIST pre 
xml : space 
%coreattrs ; 



" (# PCDATA | a | anchor | do 
strong | input | select ) * 

CDATA #FIXED "preserve" 



br | i | b | em 



: ! ENTITY quot 
: ! ENTITY amp 
:! ENTITY apos 
:! ENTITY It 
:! ENTITY gt 
: ! ENTITY nbsp 
:! ENTITY shy 



"&#34 
"&#3 8 
"&#3 9 
"&#3 8 
"&#62. 
"&#16 0; " 
"­ 



#38; "> 
#60; "> 



-- quotation mark --> 

-- ampersand --> 

-- apostrophe --> 

-- less than --> 

-- greater than --> 

-- non-breaking space --> 

-- soft hyphen (discretionary hyphen) 



13.3 Reserved Words 

WML reserves the use of several strings for future uses. These strings may not be used in any DTD 
or extension of WML. The following words are reserved: 

style 
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14. A Compact Binary Representation of WML 



WML may be encoded using a compact binary representation. This content format is based upon 
the WAP Binary XML Content Format [WBXML]. 



Conformance Rules: 




WML-60 WML token table 


M 



14.1 Extension Tokens 



14.1.1 Global Extension Tokens 

The [WBXML] global extension tokens are used to represent WML variables. Variable references 
may occur in a variety of places in a WML deck (see section 10.3). There are several codes that 
indicate variable substitution. Each code has different escaping semantics (e.g., direct substitution, 
escaped substitution and unescaped substitution). The variable name is encoded in the current 
document character encoding and must be encoded as the specified in the source document (e.g., 
variable names may not be shortened, mapped or otherwise changed). For example, the global 
extension token EXT_I_0 represents an escaped variable substitution, with the variable name 
inline. 

14.1.2 Tag Tokens 

WML defines a set of single-byte tokens corresponding to the tags defined in the DTD. All of 
these tokens are defined within code page zero. 

14.1.3 Attribute Tokens 

WML defines a set of single-byte tokens corresponding to the attribute names and values defined in 
the DTD. All of these tokens are defined within code page zero. 

14.2 Encoding Semantics 
14.2.1 Encoding Variables 

All valid variable references must be converted to variable reference tokens (e.g., EXT_I_0). The 
encoder must validate that a variable reference uses proper syntax. The encoder should also 
validate that the placement of the variable reference within the WML deck is valid. 
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14.2.2 Encoding Tag and Attributes Names 

All tag and attribute names, for which binary token values are defined in this specification, must be 
tokenised, literal tokens must not be used. The user-agent must, however, treat literal and binary 



tokens as equivalent. See [WBXML]. 


Conformance Rules: 




WML-61 XML Well-formed 


M 


WML-62 XML Validation 


0 



14.2.3 Document Validation 



XML document validation (see [XML]) should occur during the process of tokenising a WML deck 
and must be based on the DOCTYPE declared in the WML deck. When validating the source text, 
the tokenisation process must accept any DOCTYPE or public identifier, if the document is 
identified as a WML media type (see section 13.1.2). 

The tokenisation process should notify the user of any well-formedness or validity errors detected 
in the source deck. 

14.2.3.1 Validate %length; 

The WML tokenisation process should validate that attribute values defined as % length ; contain 
either a NMTOKEN or a NMTOKEN followed by a percentage sign character. For example, the 
following attributes are legal: 

vspace="100%" 
hspace= " 123 " 

% length ; data is encoded using normal attribute value encoding methods. 

14.2.3.2 Validate %vdata; 

The WML tokenisation process must validate the syntax of all variable references within attribute 
values defined as %vdata; or %HREF ; according to section 10.3.5. It must also verify that other 
CDATA attribute values do not contain any variable references. Attribute values not defined in the 
DTD must be treated as %vdata ; and validated accordingly. 
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14.3 Numeric Constants 

14.3.1 WML Extension Token Assignment 

The following global extension tokens are used in WML and occupy document-type-specific token 
slots in the global token range. As with all tokens in the global range, these codes must be reserved 
in every code page. All numbers are in hexadecimal. 



Table 4. Global extension token assignments 



Token .\iune 


Token 


Description 


EXTIO 


40 


Variable substitution - escaped. Name of the variable 
is inline and follows the token as a termstr. 


EXTIl 


41 


Variable substitution - unescaped. Name of the 
variable is inline and follows the token as a 
termstr. 


EXTI2 


42 


Variable substitution - no transformation. Name of 
the variable is inline and follows the token as a 
termstr. 


EXTTO 


80 


Variable substitution - escaped. Variable name 
encoded as a reference into the string table. 


EXTT1 


81 


Variable substitution - unescaped. Variable name 
encoded as a reference into the string table. 


EXTT2 


82 


Variable substitution - no transformation. Variable 
name encoded as a reference into the string table. 


EXTO 


CO 


Reserved for future use. 


EXTl 


CI 


Reserved for future use. 


EXT_2 


C2 


Reserved for future use. 



14.3.2 Tag Tokens 



The following token codes represent tags in code page zero (0). All numbers are in hexadecimal. 
Table 5. Tag tokens 



© Copyright Wireless Application Protocol Forum.Ltd, 1998, 1999, 2000. 

All rights reserved 



WAP-191-WML, 19 February 2000 



Page 99 (110) 



Tan Same 


Token 


a 


1C 


anchor 


22 


access 


23 


b 


24 


big 


25 


br 


26 


card 


27 


do 


28 


em 


29 


fieldset 


2A 


go 


2B 


head 


2C 


i 


2D 


img 


2E 


input 


2F 


meta 


30 


noop 


31 


P 


20 



Tan Same 


Token 


postfield 


21 


pre 


IB 


prev 


32 


onevent 


33 


optgroup 


34 


option 


35 


refresh 


36 


select 


37 


setvar 


3E 


small 


38 


strong 


39 


table 


IF 


td 


ID 


template 


3B 


timer 


3C 


tr 


IE 


u 


3D 


wml 


3F 



14.3.3 Attribute Start Tokens 



The following token codes represent the start of an attribute in code page zero (0). All numbers are 
in hexadecimal. 



Table 6. Attribute start tokens 



Alirihuie Same 


Alivihuie 1 alue 


Token 




Ami huic \ume 


Ami haie f alue 


Token 
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Amibmc \iiiiu' 


Ami huw 1 ill iif 

Li=^ 


Token 


accept-charset 




5 


accesskey 




5E 


align 




52 


align 


bottom 


6 


align 


center 


7 


align 


left 


8 


align 


middle 


9 


align 


right 


A 


align 


top 


B 


alt 




C 


cache-control 


no-cache 


64 


class 




54 


columns 




53 


content 




D 


content 


application/vn 
d.wap.wmlc;c 
harset= 


5C 


domain 




F 


emptyok 


false 


10 


emptyok 


true 


11 


enctype 




5F 


enctype 


application/x- 

www-form- 

urlencoded 


60 


enctype 


multipart/for 


61 



© Copyright 





Prefix 






m-data 




format 




12 


forua 


false 


56 


forua 


true 


57 


height 




13 


href 




4A 


href 


http:// 


4B 


href 


https:// 


4C 


hspace 




14 


http-equiv 




5A 


http-equiv 


Content-Type 


5B 


http-equiv 


Expires 


5D 


id 




55 


ivalue 




15 


iname 




16 


label 




18 


localsrc 




19 


maxlength 




1A 


method 


get 


IB 


method 


post 


1C 


mode 


nowrap 


ID 


mode 


wrap 


IE 


multiple 


false 


IF 
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Amihuie \iime 


A mi huw 1 ill iif 


Token 


multiple 


true 


20 


name 




21 


newcontext 


false 


22 


newcontext 


true 


23 


onenterbackward 




25 


onenterforward 




26 


onpick 




24 


ontimer 




27 


optional 


false 


28 


optional 


true 


29 


path 




2A 


scheme 




2E 


sendreferer 


false 


2F 


sendreferer 


true 


30 


size 




31 


src 




32 


src 


http:// 


58 


src 


https:// 


59 


ordered 


true 


33 


ordered 


false 


34 


tabindex 




35 


title 




36 



A mi huh' A «/;;<' 


Ami huh' I ulue 
Prefix 


Token 


type 




37 


type 


accept 


38 


type 


delete 


39 


type 


help 


3A 


type 


password 


3B 


type 


onpick 


3C 


type 


onenterbackw 
ard 


3D 


type 


onenterforwar 
d 


3E 


type 


ontimer 


3F 


type 


options 


45 


type 


prev 


46 


type 


reset 


47 


type 


text 


48 


type 


vnd. 


49 


value 




4D 


vspace 




4E 


width 




4F 


xmklang 




50 


xml: space 


preserve 


62 


xml: space 


default 


63 
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14.3.4 Attribute Value Tokens 



The following token codes represent attribute values in code page zero (0). All numbers are in 
hexadecimal. 



Table 7. Attribute value tokens 



. Ut rib ute \ a hie 


Token 


.com/ 


85 


.edu/ 


86 


.net/ 


87 


.org/ 


88 


accept 


89 


bottom 


8A 


clear 


8B 


delete 


8C 


help 


8D 


http:// 


8E 


http://www. 


8F 


https:// 


90 


https://www. 


91 


middle 


93 



. Ut rib ute I at ne 


Token 


nowrap 


94 


onenterbackward 


96 


onenterforward 


97 


onpick 


95 


ontimer 


98 


options 


99 


password 


9A 


reset 


9B 


text 


9D 


top 


9E 


unknown 


9F 


wrap 


AO 


Www. 


Al 
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14.4 WML Encoding Examples 

Refer to [WBXML] for additional examples. 

The following is another example of a tokenised WML deck. It demonstrates variable encoding, 
attribute encoding and the use of the string table. Source deck: 

<wml> 

<card id="abc" ordered="true"> 
<P> 

<do type=" accept "> 

<go href="http://xyz .org/s"/> 
</do> 

X: $(X)<br/> 

Y: $ (&#x5 9; ) <br/> 

Enter name: <input type="text" name="N"/> 
</p> 
</card> 
</wml> 

Tokenised form (numbers in hexadecimal) follows. This example only uses inline strings and 
assumes that the character encoding uses a NULL terminated string format. It also assumes that the 
character encoding is UTF-8: 



02 


08 


6A 


04 


'X' 


00 


' Y" 


00 


7F 


E7 


55 


03 


' a ' 


'b' 


' c ' 


00 


33 


01 


60 


E8 


38 


01 


AB 


4B 


03 


' x ' 


'y' 


' z ' 


00 


88 


03 




' s ' 


00 


01 


01 


03 




'X' 






00 


82 


00 


26 


03 




' Y 






00 


82 


02 


26 


03 




'E' 


' n ' 


' t ' 


' e ' 


i r i 




' n ' 




' a ' 


' m' 


' e ' 






00 


AF 


48 


21 


03 


' N ' 


00 


01 


01 


01 


01 



In an expanded and annotated form: 



Table 8. Example tokenised deck 



Token Stream 


Description 


02 


WBXML Version number 1.2 


08 


WML 1.2 Public ID 


6A 


Charset=UTF-8 (MIBEnum 106) 


04 


String table length 


'X', 00, 'Y', 00 


String table 


7F 


wml, with content 
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Token Strewn 


Dcscripfio n 


E7 


card with content and. attributes 


55 


id= 


03 


Inline string follows 






33 


ordered= " true " 


01 


END (of card, attribute list) 


60 




E8 


do with content and. attributes 


38 


type= accept 


01 


END (of do attribute list) 


AB 


c[0 with attributes 


4B 


href="http://" 


03 


Inline string follows 


'x 1 , 'y'/ 'z 1 , oo 




88 




03 


Inline string follows 


' s ' , 00 


string 


01 


END (of go element) 


01 


END (of do element) 


03 




' ' , 'X' , ' : ' , ' ' , 00 




82 


Direct variable reference (EXT T 2 ) 


00 


Variable offset 0 
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26 


br 


03 




' ' , ' Y' , ' : ' , ' ' , 00 




82 


Direct variable reference (EXT T 2 ) 


02 




26 


br 


03 


Inline string follows 


' ' , 1 E ' , 'n', 't', 'e', ' r ' , ' 
' , ' n ' , 'a', ' m' , ' e ' , ':', ' ' , 

00 


String 


AF 


input with attributes 


48 


typ6= " tGXt " 


21 




03 




' N ' , 00 




01 


END (of input attribute list) 


01 


END (of p element) 


01 


END (of card element) 


01 


END (of wml element) 
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15. Static Conformance Statement 

This section defines the static conformance requirements for the WML user agent, documents, and 
encoder. 



15.1 WML User Agent 

15.1.1 Character Set and Encoding 



Item 


I- unction 


Rl'flTCIK'C 


Mandatory 
/Optional 


WML-01 


UTF-8 Encoding 


6 


O 


WML-02 


UTF-16 Encoding 


6 


O 


WML-03 


UCS-4 Encoding 


6 


0 


WML-04 


Other character 
encoding 


6 


0 


WML-05 


Reference processing 


6.1 


M 


WML-06 


Character entities 


6.2 


M 



15.1.2 Events and Navigation 



Item 


I'u notion 


RcfdTIKT 


Mandator} 
/Optional 


WML-07 


History 


9.2 


M 


WML-08 


Card/Deck task 
Shadowing 


9.6 


M 


WML-09 


Intrinsic Events 


9.10 


M 



15.1.3 State Model 



Item 


I'u notion 


RcfdTIKT 


Mandatory 
/Optional 


WML- 10 


Browser context 


10.1 


M 


WML- 11 


Initialisation 
(newcontext) 


10.2 


M 


WML- 12 


Variables 


10.3 


M 


WML- 13 


Context restrictions 


10.4 


M 
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Item 


1- unction 


Reference 


Mandator} 
/Optional 


WML- 14 


Deck access control 


12.1 


M 


WML- 15 


Low-memory 
behaviour 


12.2 


O 


WML- 16 


Error handling 


12.3 


M 


WML- 17 


Unknown DTD 
handling 


12.4 


M 


WML- 18 


Inter-card navigation 


12.5 


M 



15.1.5 Elements 



If a user agent does not support an optional element, it should continue to process the children of 
the element. The children of an element include all elements and character data. 



Item 


K lenient 


Reference 


Mandator} 
/Optional 


WML- 19 




9.9 


M 


WML-20 


anchor 


9.8 


M 


WML-21 


access 


11.3.1 


M 


WML-22 


b 


11.8.2 


O 


WML-23 


big 


11.8.2 


O 


WML-24 


br 


11.8.4 


M 


WML-25 


card 


11.5 


M 


WML-26 


do 


9.7 


M 


WML-27 


em 


11.8.2 


O 


WML-28 


fieldset 


11.6.4 


O 


WML-29 


go 


9.5.1 


M 


WML-30 


head 


11.3 


M 


WML-31 




11.8.2 


O 


WML-32 


img 


11.9 


M 


WML-33 


input 


11.6.3 


M 


WML-34 


meta 


11.3.2 


O 


WML-35 


noop 


9.5.4 


M 


WML-36 


P 


11.8.3 


M 


WML-37 


postfield 


9.3 


M 


WML-75 


pre 


11.8.9 


O 
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Item 


i 

I*- lenient 


Reference 


Mandator) 
/Optional 


WML-38 


prev 


9.5.2 


M 


WML-39 


onevent 


9.10.1 


M 


WML-40 


optgroup 


11.6.2.3 


O 


WML-41 


option 


11.6.2.2 


M 


WML-42 


refresh 


9.5.3 


M 


WML-43 


select 


11.6.2.1 


M 


WML-44 


small 


11.8.2 


O 


WML-45 


strong 


11.8.2 


O 


WML-46 


table 


11.8.5 


M 


WML-47 


template 


11.4 


M 


WML-48 


timer 


11.7 


M 


WML-49 


td 


11.8.7 


M 


WML-50 


tr 


11.8.6 


M 


WML-51 


u 


11.8.2 


O 


WML-52 


setvar 


9.4 


M 


WML-53 


wml 


11.2 


M 



15.1.6 Image Support 



Item 


1- unction 


Reference 


Mandatory/Optional 


WML-54 


Display of alt attribute 
of <img> 


11.9 


IF NOT WAE-GRIM: M 


WML-55 


Support for vspace hint 


11.9 


WAE-GRIM:0 


WML-56 


Support for hspace hint 


11.9 


WAE-GRIM:0 


WML-57 


Support for <img> 
align 


11.9 


WAE-GRIM:0 


WML-58 


Support for <img> 
height 


11.9 


WAE-GRIM:0 


WML-59 


Support for <img> 
width 


11.9 


WAE-GRIM:0 
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15.2.1 Token Table 



Item 


1- unction 


Reference 


Mandator} 
/Optional 


WML-60 


WML token table 


14 


M 


15.2.2 Validation 


Item 


1- unction 


Reference 


Mandator} 
/Optional 


WML-61 


XML Well-formed 


14.2.2 


M 


WML-62 


XML Validation 


14.2.2 


0 


WML-63 


WML Validation 


15.3 


0 


15.3 WML Document - Server 


Item 


1- unction 


Reference 


/Optional 


WML-64 


Variable references 
may only occur in 
vdata attribute values 


7.5 


M 


WML-65 


Variable references 
must match the 
production rule var 


10.3.1 


M 


WML-66 


Two or more do 
elements with the same 
name must not be 
present in a single card 
or in the template 
element. (Note: An 
unspecified name 
defaults to the value of 
the type attribute.) 


9.7 


M 


WML-67 


A meta element must 
not contain more than 
one attribute of name 
and http-equiv 


11.3.2 


M 



© Copyright Wireless Application Protocol Forum.Ltd, 1998, 1999, 2000. 

All rights reserved 



WAP-191-WML, 19 February 2000 



Page 110 (110) 





1* unction 


Reference 


Mandator) 
/Optional 


WML-68 


The number of columns 
in a table must not be 
set to zero 


11.8.5 


M 


WML-69 


Event bindings must 
not conflict 


9.10 


M 


15.4 WML Document -Client 


Item 


I- unction 


Reference 


Mandator) 
/Optional 


WML-70 


Variable references 
must match the 
production rule var 


10.3.1 


O 


WML-71 


Two or more do 
element with the same 
name must not be 
present in a single card 
or in the template 
element. (Note: An 
unspecified name 
defaults to the value of 
the type attribute.) 


9.7 


O 


WML-72 


A meta element must 
not contain more than 
one attribute of name 
and http-equiv 


11.3.2 


0 


WML-73 


The number of columns 
in a table must not be 
set to zero 


11.8.5 


0 


WML-74 


Event bindings must 
not conflict 


9.10 


0 



© Copyright Wireless Application Protocol Forum.Ltd, 1998, 1999, 2000. 

All rights reserved 



